Nested strong loader apparatus and method

• US 7,383,442 B2
• Filed: 10/24/2002
• Issued: 06/03/2008
• Est. Priority Date: 03/23/1998
• Status: Expired due to Term

• Current Assignee: Emc IP Holding Company LLC (Dell Technologies Inc.)
• Original Assignee: Novell Incorporated (Open Text Corporation)
• Inventors: Kingdon, Kevin W., Schell, Roger R., Berson, Thomas A.
• Primary Examiner(s): Sheikh; Ayaz
• Assistant Examiner(s): Sherkat; Arezoo
• Application Number:
  US10/279,517
• Publication Number:
  US 20030061483A1
• Time in Patent Office: 2,049 Days
• Field of Search: None
• US Class Current: 713/188
• CPC Class Codes: G06F 21/602 Providing cryptographic facilities or services
• CPC Class Codes: G06Q 20/3674 involving authentication
• CPC Class Codes: G06Q 20/383 Anonymous user system
• CPC Class Codes: H04L 63/04 for providing a confidential data exchange among entities communicating through data packet networks
• CPC Class Codes: H04L 63/0428 wherein the data content is protected, e.g. by encrypting or encapsulating the payload

Abstract

An apparatus and method provides one or more controlled, dynamically loaded, modular, cryptographic fillers. Fillers may be loaded by a single loader, multiple independent loaders, or nested loaders. Loaders may be adapted to load other loaders, within cryptographic controls extant and applicable thereto. Integration into a base executable having one or more slots, minimizes, controls, and links the interface between the fillers and base executables. The filler may itself operate recursively to load another filler in nested operations, whether or not the fillers are in nested relation to one another. An ability of any filler to be loaded may be controlled by the base executable verifying the integrity, authorization, or both for any filler. The base executable may rely on an integrated loader to control loading and linking of fillers and submodules. A policy may limit each module function, access, and potential for modification or substitution. Dynamically loaded modules (loaders, other fillers, and submodules thereof), typically represent a relatively small portion of the overall coding required by the base executable, and may provide strong controls limiting integration by providing access that is nested, layered, or both between modules excluding direct access to or by them from the base executable or supported applications.

Claims

1. A method to limit software module integration, comprising:

receiving a first filler module having a first unique property;

dynamically loading the first filler module into a base module using the first loader after the first unique property is verified by the first loader, wherein the base module when loaded with the first filler module permits the first filler module to be executed;

processing a second loader of the first filler module; and

dynamically loading a second filler module after the second loader verifies a second unique property of a second filler module, wherein the second filler module when loaded is capable of being executed, and wherein the first and second loaders are independent loaders from one another.

2. The method of claim 1 wherein in receiving, the base module includes a plurality of slots for integrating the first and second filler modules with the base module after the first unique property and the second unique property are verified.

3. The method of claim 1 wherein in receiving, the base module is an operating system processing on one or more processors.

4. The method of claim 1 wherein in dynamically loading the first and second filler modules, the filler modules are modules wrapped with cryptographic information that identifies the first and second unique properties.

5. The method of claim 4 wherein in dynamically loading the first and second filler modules, the cryptographic information defines access rights to and/or interaction rights between the first and second filler modules with the first and second unique properties.

6. The method of claim 1 wherein in dynamically loading the second filler module, the second loader dynamically links a plurality of addition modules of the second filler module to one another in a layered hierarchy.

7. The method of claim 1 wherein in dynamically loading the first and second filler modules, the first and second unique properties are associated with access policies.

8. A method to verify software module integration, comprising:

identifying a first unique property of a first filler module;

verifying the first unique property before permitting the first filler module to load before subsequent processing;

authorizing the first filler module to process when verified and loaded, and wherein the first filler module acquires a second unique property of a second filler module;

verifying the second unique property by the first filler module before permitting the second filler module to load before subsequent processing; and

authorizing the second filler module for processing when it is verified and loaded, and wherein the first filler module is loaded with an independent loader that is different from a loader that loads the second filler module.

9. The method of claim 8, wherein in verifying the first and second unique properties, the first unique property is verified by a base loader module and the second unique property is verified by a first filler loader module.

10. The method of claim 8 wherein in identifying the first unique property, the first unique property is verified by a base module integrated into and/or with an operating system.

11. The method of claim 8 wherein in verifying the first and second unique properties, the unique properties are verified by authenticating digital signatures and/or digital certificates associated with the first and second filler modules.

12. The method of claim 8 wherein in authorizing the first and second filler modules for processing, the first and second filler modules are dynamically linked with one another and an operating system before processing.

13. The method of claim 8 wherein in verifying the first and second unique properties, the first and second unique properties are wrapped around the first and second filler modules, respectively, and wherein the unique properties and filler modules are electronically distributed as one or more data structures.

14. The method of claim 13 wherein in verifying the first and second unique properties, the data structures are generated by a software development kit after the filler modules are manufactured.

15. A data structure used for dynamically integrating software modules residing in a computer readable medium, the data structure comprising:

one or more certificates for dynamically authenticating accesses desired by one or more holders of the certificates that desire use of the data structure;

one or more policies for defining access rights and/or interaction rights of the one or more holders to one or more modules;

a policy manager for dynamically enforcing the one or more policies; and

the one or more modules being accessed by the one or more holders, wherein each module includes a loader module for dynamically authenticating and dynamically loading one or more of the remaining modules, and wherein each module is available for execution when loaded, and wherein each loader is independent from other remaining ones of the loaders.

16. The data structure of claim 15, wherein the data structure is dynamically provided to an operating system for use in authenticating holders and interactions between the one or more modules.

17. The data structure of claim 15 further comprising, one or more cryptographic engines for dynamically authenticating the one or more certificates.

18. The data structure of claim 17 further comprising, a base module associated with each of the one or more modules for plugging into and interfacing with one or more slots of an operating system.

19. The data structure of claim 15, wherein each certificate includes a signature, a public key, and an identifier for one of the holders.

20. The data structure of claim 15, wherein data structure resides in volatile memory of an operating system and is used by the operating system to manage interactions and accesses of the one or more holders to the one or more modules.