System and method for secure authentication of external software modules provided by third parties

• US 20050216422A1
• Filed: 05/06/2005
• Published: 09/29/2005
• Est. Priority Date: 09/08/2000
• Status: Active Grant

• Current Assignee: International Business Machines Corporation
• Original Assignee: International Business Machines Corporation
• Inventors: Lotspiech, Jeffrey B., Nusser, Stefan, Rettig, Paul R.
• Granted Patent: US 7,500,109 B2
• Time in Patent Office: Days
• US Class Current: 705/66
• CPC Class Codes: G06F 21/64 Protecting data integrity, e.g. using checksums, certificates or signatures
• CPC Class Codes: G06Q 20/3672 initialising or reloading thereof
• CPC Class Codes: H04L 2209/56 Financial cryptography, e.g. electronic payment or e-cash
• CPC Class Codes: H04L 2209/60 Digital content management, e.g. content distribution
• CPC Class Codes: H04L 9/32 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
• CPC Class Codes: H04L 9/3234 involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token network architectures or network communication protocols for supporting authentication of entities using an additional device in a packet data network H04L63/0853
• CPC Class Codes: H04L 9/3249 using RSA or related signature schemes, e.g. Rabin scheme

Abstract

An external module loads into an entity'"'"'s memory and is transformed by two functions. These are namely, the STOMP function and the UNSTOMP function. One or both of these functions is based on the actual code that is found in a legitimate version of the external module. The STOMP-UNSTOMP pair produces an external module that works differently if even a single byte of code in the external module has been changed by an attacker. The STOMP transforms the external module and makes it temporarily unusable whilst conversely, the UNSTOMP repairs the damage and makes it workable again. Thus, if the module is not authentic, the pairing between the STOMP and UNSTOMP is broken. Therefore, a patched module from a hacker remains unusable since the STOMP and UNSTOMP transformations do not produce a working external module. Because of the STOMP and UNSTOMP technique, an application is secure because if an external module is free from tampering then the application executes normally. In the event that an illicitly patched external module is loaded then the application fails. In either case, no audio, video or information content is illegally copied because of the disablement of the external module by the STOMP-UNSTOMP procedure.

Claims

1. A computer system for secure authentication of executable external modules, comprising:

memory for storing

an executable external module whose authenticity is to be verified,

data K that can be created by using two different schemes, at least one scheme of the two different schemes being based on the integrity of a module to be verified, and

an authentication token for the module to be verified which produces data K in both schemes, the executable external module being representative of the module to be verified; and

a processor, communicatively coupled to the memory, for

using data K as created by one scheme of the two different schemes to disrupt the executable external module; and

using data K as created by the other scheme of the two different schemes to restore the executable external module from the disrupted executable external module thereby authenticating said executable external module.

2. The computer system of claim 1, wherein:

the processor for performing at run time of the executable external module at the computer system the

using data K as created by one scheme of the two different schemes to disrupt the executable external module, and

using data K as created by the other scheme of the two different schemes to restore the executable external module from the disrupted executable external module thereby authenticating said executable external module.

3. The computer system of claim 1, wherein:

the disrupting of the executable external module is performed by a STOMP process and the restoring of the executable external module is performed by an UNSTOMP process.

4. The computer system of claim 1, wherein one or more of the schemes is based on at least one of RSA encryption and digital signets.

5. The computer system of claim 1, wherein:

a public component of one or more of the schemes is embedded in a verification code of the executable external module.

6. The computer system of claim 1, wherein:

the authentication token is embedded in the executable external module and the executable external module itself remaining functional.

7. The computer system of claim 6, where the authentication token is embedded in the executable external module by adding an additional data section to a DLL in Portable Executable (PE) format.

8. The computer system of claim 1, wherein the authentication token is external to the executable external module.

9. The computer system of claim 1, wherein the at least one scheme based on the integrity of the module to be verified is independent of a location of the executable external module in memory.

10. The computer system of claim 9, wherein location independence is achieved by a canonical hash.

11. A computer readable medium comprising computer instructions including instructions for authenticating an external module comprising:

providing data K that can be created by using two different schemes, at least one scheme of the two different schemes being based on the integrity of a module to be verified;

providing an authentication token for said module which produces data K in both schemes, an executable external module being representative of said module;

at a computer system, using data K as created by one scheme of the two different schemes to disrupt said executable external module; and

at the computer system, using data K as created by the other scheme of the two different schemes to restore the executable external module from the disrupted executable external module thereby authenticating said executable external module.

12. The computer readable medium of claim 11, wherein the disrupting of the executable external module is performed by a STOMP process and the restoring of the executable external module is performed by an UNSTOMP process.

13. The computer readable medium of claim 12, wherein

the STOMP process, at the computer system, disrupts the executable external module by

decrypting a number of pseudo-random bytes that are part of the authentication token using a public security code of a public and private component pair security code;

and

XORing the decrypted pseudo-random bytes with the executable external module thereby disrupting the executable external module into an unusable state; and

the UNSTOMP process, at the computer system, restores the executable external module in the unusable state by

performing a signet extrication process to generate extrication data by using the hash of the executable external module in the unusable state;

using the extrication data to generate another stream of pseudo-random bytes; and

XORing the another stream of pseudo-random bytes with the executable external module in the unusable state thereby

restoring, from the executable external module in the unusable state, the executable external module back to a usable state in the event there has been no illicit patching of the executable external module, and

maintaining the executable external module in an unusable state in the event that the executable external module has been illicitly patched such that an application or program that is accessing the executable external module in the unusable state fails to operate.

14. The computer readable medium of claim 11, wherein one or more of the schemes is based on RSA encryption.

15. The computer readable medium of claim 11, wherein one or more of the schemes is based on digital signets.

16. The computer readable medium of claim 11, wherein:

a public component of one or more of the schemes is embedded in a verification code of the executable external module.

17. The computer readable medium of claim 11, wherein:

the authentication token is embedded in the executable external module and the executable external module itself remaining functional.

18. The computer readable medium of claim 17, where the authentication token is embedded in the executable external module by adding an additional data section to a DLL in Portable Executable (PE) format.

19. The computer readable medium of claim 11, wherein the authentication token is external to the executable external module.

20. The computer readable medium of claim 11, wherein the at least one scheme based on the integrity of the module to be verified is independent of a location of the executable external module in memory.

21. The computer readable medium of claim 20, wherein location independence is achieved by locating and reading the executable external module'"'"'s image on a disk.

22. The computer readable medium of claim 20, wherein location independence is achieved by using a canonical hash.

23. The computer readable medium of claim 11, wherein:

the using data K as created by one scheme to disrupt said executable external module, and

the using data K to restore the executable external module from the disrupted executable external module,

are performed at run time of the executable external module at the computer system.

24. The computer readable medium of claim 11, further comprising the instructions for:

re-authenticating, at the computer system, the executable external module by periodically performing the disrupting of the executable external module and the restoring of the executable external module multiple times while interacting with the executable external module at the computer system.

25. The computer readable medium of claim 11, further comprising the instructions for:

performing run time checks of the executable external module to make sure that function calls to the executable external module are not intercepted by an attacker.