Electrical computers and digital processing systems: support – Multiple computer communication using cryptography – Particular communication authentication technique
Reexamination Certificate
1999-10-19
2003-04-08
Hayes, Gail (Department: 2131)
Electrical computers and digital processing systems: support
Multiple computer communication using cryptography
Particular communication authentication technique
C713S152000, C713S152000, C713S152000, C713S176000, C713S187000, C713S189000
Reexamination Certificate
active
06546487
ABSTRACT:
The present invention relates to systems and methods for restricting the use of executable modules such that each executable module can be dynamically linked only to other executable modules whose authenticity has been verified.
BACKGROUND OF THE INVENTION
In the context of a computer program, an “external function” is typically a procedure or function located in a library or other repository of functions that is external to the computer program using the external function. External functions are often, but not always, authored by different people or by different entities than the computer programs using those external functions.
Program execution environments that allow external functions to be bound at run time, rather than at link time or compile time, facilitate the maintenance and updating of computer programs because for such programs to be used in such execution environments only the computer programs that are being revised or updated need to be recompiled, while the other modules can be left unchanged. Furthermore, the recompilation process is simplified because the compilation of the revised programs can be performed even if other modules used by the program are not present in the program development system.
However, systems using such program execution environments are vulnerable, because the interfaces between the program modules are usually well specified, or can be determined by third parties, and it is possible for such third parties to therefore use those program modules in ways not sanctioned by the corresponding software license agreements. Alternately, such third parties can allow the system to be subverted by replacing authentic program module with corrupted ones.
This problem is magnified when dealing with cryptographic routines in software that is destined for export from the United States of America to customers or distributors in other countries. It is currently forbidden by U.S. trade law to export software modules that provide general cryptographic capabilities. On the other hand, it is allowed to export programs that use cryptographic capabilities in a limited context and that cannot be used to perform general cryptographic functions outside the limited context of the exported program. In fact, it is commercially important to be able to design software systems for export that use cryptographic functions in an authorized manner. Prior art late bound systems, such as dynamic link libraries (DLLs in the Windows system) or shared objects (.so files in Solaris), attempt to solve this problem by either obscuring the interfaces between software modules, or by providing separate “export only” versions of their software. Providing separate “export only” versions of software products leads to problems in keeping the domestic and export versions “synchronized” with respect to upgrades and maintenance revisions with a single code base.
Another example of a situation where there is a need to limit or prevent use of dynamically linkable modules is an application written by a vendor that wishes to keep some functions in the application private for either trade secret or contractual reasons. Such systems require limiting access to these private functions.
SUMMARY OF THE INVENTION
In summary, the present invention is a computer system having a program module verifier and at least first and second program modules. Each of the program modules includes a digital signature and an executable procedure. The first program module furthermore includes a procedure call to the second procedure module, a procedure call to the program module verifier that is logically positioned in the first program module so as to be executed prior to execution of the procedure call to the second program module, and instructions preventing execution of the procedure call to the second program module when the procedure call to the program module verifier results in a verification denial being returned by the program module verifier.
The second program module includes an executable procedure to be performed in response to the procedure call by the first program module to the second program module, a procedure call to the program module verifier that is logically positioned in the second program module so as to be executed prior to completion of execution of the second program module's executable procedure, and instructions preventing completion of execution of that executable procedure when the program module verifier returns a verification denial with respect to the first program module.
The program module verifier responds to procedure calls by verifying the authenticity of any specified program module and by returning a verification confirmation or denial in response to each such procedure call. More specifically, in a preferred embodiment, the program verifier module includes instructions for responding to a procedure call requesting verification of a specified program module by (A) decoding a digital signature in the specified program module with a corresponding decoding key, (B) generating a message digest of at least a portion the specified program module in accordance with a message digest function, (C) returning a verification confirmation when the decoded digital signature matches the message digest, and (D) returning a verification denial when the decoded digital signature does not match the message digest.
In the preferred embodiment, when the program module verifier fails to verify the authenticity of the second program module, the first program module throws an exception and aborts its execution. Similarly, when the program module verifier fails to verify the authenticity of the first program module, the second program module throws an exception and aborts its execution.
REFERENCES:
patent: 5224160 (1993-06-01), Paulini et al.
patent: 5339403 (1994-08-01), Parker
patent: 5343527 (1994-08-01), Moore
patent: 5349642 (1994-09-01), Kingdon
patent: 5421006 (1995-05-01), Jablon et al.
patent: 5737523 (1998-04-01), Callaghan et al.
patent: 5742759 (1998-04-01), Nessett et al.
patent: 5748739 (1998-05-01), Press
patent: 5757914 (1998-05-01), McManis
patent: 5970145 (1999-10-01), McManis
Schneier, Applied Cryptography 2e, pp. 34-35, Oct. 1995.*
Smith, The Scientist and Engineer's Guide to Digital Signal Processing, California Technical Pub, p. 616, 1997.*
Goodyear, Signal and Information, Wiley, p. 1, 1971*
Bell, Information Theory and its Engineering Applications, Pitman, p. 53, 1962.*
Terman, Electronic and Radio Engineering McGraw-Hill 4e, p. 7, Oct. 95.*
Gustavus Simmons, Contemporary Cryptology, The Science of Information Integrity, IEEE, 1992, pp. 181-201.*
Gosling J. et al. “The Java Language Environment,”A White Paper, p. 1,4-85.
Hayes Gail
Pennie & Edmonds LLP
Seal James
Sun Microsystems Inc.
Williams Gary S.
LandOfFree
System and method for protecting use of dynamically linked... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method for protecting use of dynamically linked..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for protecting use of dynamically linked... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3016899