Electrical computers and digital processing systems: support – Data processing protection using cryptography – Upgrade/install encryption
Reexamination Certificate
2000-01-14
2004-04-13
Peeso, Thomas R. (Department: 2132)
Electrical computers and digital processing systems: support
Data processing protection using cryptography
Upgrade/install encryption
C713S152000, C713S152000
Reexamination Certificate
active
06721888
ABSTRACT:
BACKGROUND
This invention relates generally to computer systems, and more particularly to a mechanism for merging multiple policies to derive a resultant policy.
For a number of years, the U.S. Department of Commerce has regulated, and at times, prohibited the exportation of computer programs or applications which implement data encryption algorithms. Currently, computer programs cannot, as a general rule, be exported if they implement encryption algorithms having cryptographic key sizes exceeding a certain number of bits (the specific allowable key size is algorithm-specific). There are certain exceptions to this rule. One exception is that if an exemption mechanism is implemented, the key size, and hence the cryptographic strength of the program, may in some cases be increased. Examples of exemption mechanisms include key escrow, key recovery, and key weakening. Also, certain types of programs are allowed to use larger key sizes than others. For example, current regulations allow health care and financial services applications to use larger key sizes because of the need for increased security (to protect highly sensitive data) in these types of applications. While some applications may enjoy greater latitude than others, all encryption applications are subject to export regulations.
These regulations apply not only to programs which directly implement encryption algorithms, but also to programs which interface with programs that directly implement encryption algorithms. These programs include “framework” programs which provide infrastructure for facilitating interaction between various programs. The framework itself may not implement any encryption algorithm, but it may allow one or more programs which do implement encryption algorithms to interface with or “plug in” to the framework. An example of such a framework is the Java Cryptography Extension to the Java Platform manufactured by Sun Microsystems, Inc. of Palo Alto, Calif. If a framework allows an encryption mechanism to be “plugged in” to the framework, the framework itself will be subject to export regulations. This means that in order to be exportable, the framework needs to ensure that all export regulations are adhered to regardless of the encryption implementation that is plugged in to the. framework. In order to do this, the framework needs to have some mechanism for enforcing the necessary restrictions on the encryption implementations.
SUMMARY OF THE INVENTION
In accordance with the present invention, there is provided a mechanism for dynamically constructing customized implementations to enforce restrictions on services. For purposes of the present invention, a service is defined broadly to encompass any functionality requested by and provided to an application, including but not limited to encryption/decryption functionality. In one embodiment, the invention is implemented in a system comprising an application, a general implementation of a particular service, and a framework.
The framework receives from the application a request for an implementation of a particular service, such as an implementation of a particular encryption algorithm. In response, the framework determines what restrictions, if any, need to be imposed on the requested implementation. In one embodiment, the framework determines the restrictions based upon a set of specified limitations and upon permissions, if any, granted to the application. Once the restrictions are determined, the framework dynamically constructs the requested implementation. In one embodiment, the requested implementation is constructed such that it incorporates the general implementation of the service, the restrictions, and enforcement logic for enforcing the restrictions on the general implementation. Since the requested implementation is constructed specifically for the application, it is customized for the application. Thus, the implementation is referred to as the customized implementation.
Once the customized implementation is dynamically constructed, the framework provides the customized implementation to the application. Thereafter, the application invokes the customized implementation directly for services. Since the customized implementation incorporates the restrictions and enforcement logic for enforcing the restrictions, it is not necessary for the application to further interact with the framework. The customized implementation itself will provide the services, and will guarantee that the restrictions are enforced. By dynamically constructing customized implementations in this manner, the framework ensures that the necessary restrictions are enforced on the services provided to the application.
As noted above, the restrictions imposed on the customized implementation are determined based upon a set of specified limitations and upon permissions, if any, granted to the application. In one embodiment, the specified limitations are derived by merging multiple source policies. These source policies, which may represent sets of laws/regulations, and which may comprise zero or more entries with each entry comprising an identifier and a set of one or more limitations, are merged by first selecting a current entry in a first source policy. Then a determination is made as to whether there is an entry in a second source policy which corresponds to the current entry. If so, then the limitations in the current entry are processed with the limitations in the corresponding entry to derive a set of resultant limitations. The limitations are processed such that the resultant limitations comprise the most restrictive limitations of the current entry and the corresponding entry. By doing so, it is ensured that the resultant limitations comply with both the first and the second source policies. Once the resultant limitations are derived, a new entry is created in a resultant policy, and the resultant limitations are stored within the new entry. The resultant policy (which represents the set of specified limitations) is thus populated. In this manner, the set of specified limitations is derived by merging multiple source policies.
REFERENCES:
patent: 5323464 (1994-06-01), Elander et al.
patent: 5369702 (1994-11-01), Shanton
patent: 5412717 (1995-05-01), Fischer
patent: 5493692 (1996-02-01), Theimer et al.
patent: 5555376 (1996-09-01), Theimer et al.
patent: 5649099 (1997-07-01), Theimer et al.
patent: 5745572 (1998-04-01), Press
patent: 5883956 (1999-03-01), Le et al.
patent: 5907620 (1999-05-01), Klemba et al.
patent: 5933503 (1999-08-01), Schell et al.
patent: 6125446 (2000-09-01), Olarig et al.
patent: 6178504 (2001-01-01), Fieres et al.
patent: 6298445 (2001-10-01), Shostack et al.
patent: 6308266 (2001-10-01), Freeman
patent: 6389534 (2002-05-01), Elgamal et al.
patent: 6535980 (2003-03-01), Kumar et al.
patent: 2002/0112171 (2002-08-01), Ginter et al.
patent: 0 539 726 (1993-05-01), None
patent: 0 828 208 (1998-03-01), None
Roger S. Pressman, Ph.D., “Software Engineering, A Practitioner's Approach,” Fourth Edition, 1982-1987, pp. 1-22 and 549-576.
Java Cryptography Extension 1.2.1, Java Cryptography Extension 1.2.1 API Specification & Reference, downloaded May 10, 2002, http://java.sun.com/products/jce/doc/guide/API_users_guide.html, pp. 1-51.
Java(TM) Cryptography Extension (JCE), Java Cryptography Extension (JCE), http://java.sun.com/products/jce/index.html, downloaded May 10, 2002, 5 pages.
David A. Taylor, “Object-Oriented Information Systems, Planning and Implementation,” 1992, John Wiley and Sons, 369 pages.
Susan Landau, et al., “Crypto Policy Perspectives,” Communications of the ACM, Aug. 1994, vol. 37, No. 8, XP-002253003, pp. 115-121.
Fausto Rabitti, et al., “A Model of Authorization for Next-Generation Database Systems,” ACM Transactions on Database Systems, vol. 16, No. 1, Mar. 1991, XP-002254871, pp. 88-131.
Liu Sharon S.
Luehe Jan
Hickman Palermo & Truong & Becker LLP
Nicholes Christian A.
Peeso Thomas R.
Sun Microsystems Inc.
Truong Bobby K.
LandOfFree
Mechanism for merging multiple policies does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Mechanism for merging multiple policies, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Mechanism for merging multiple policies will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3199362