Browse Prior Art Database

Bootstrap provider for Java Security Disclosure Number: IPCOM000016207D
Original Publication Date: 2002-Sep-16
Included in the Prior Art Database: 2003-Jun-21

Publishing Venue



A program is disclosed allowing the bootstrapping of digitally signed security algorithms to be shipped with a Java* Virtual Machine (JVM). Allowing such algorithms to be packaged as extensions without the need for some or all of the algorithms to be integrated into the core of the JVM. The Java 2 architecture allows for extension jar files to the used, by the JVM, to extend the JVM's functionality by adding, for example, additional security algorithms. Such algorithms would be treated, in most respects, as being part of the core of the JVM. And for this reason the extension JAR files need to be digitally signed to allow the JVM to very of the origin and integrity of the code held in such extension JAR files. This can lead to a problem if all security algorithms, including those needed to verify digital signatures, are held in such extension jar files. One would need to use a digital signature algorithm to verify the algorithm being used had not been tampered with, not a very secure arrangement. The Java Cryptography Architecture (JCA) specifies that all security algorithms are listed in and accessed via providers. A provider maps a set of algorithm names to the implementing class names and are used by the JVM to decouple user code from the implementing classes. Code needing to use a security algorithm need not know the name of the implementing class. Providers are specified in a JVM configuration file, normally called, and are read during the initialisation of the JVM. The providers are implemented as Java classes and are loaded as new algorithms are required which can not be supplied by an already loaded provider. If the provider class needs to be loaded from an extension jar file it is likely that such a load would trigger the verification of the jar file's signature. The verification would require certain security algorithms to be already be available. The solution disclosed here is that a bootstrap provider, and algorithm set, is supplied with the core. It would contain just those algorithms needed to verify the signature and integrity of an extension jar file. During the initialisation of the JVM, and before the configured providers are accessed for the first time, the bootstrap provider would be loaded automatically and its algorithm's made available. As subsequent provider classes are loaded requests would be routed, via the classloader, to the security sub system for specific algorithms. These requests would be met by the bootstrap provider. Once a configured provider is loaded which can supply the same algorithms as the bootstrap provider, the bootstrap provider is unloaded. All caches which hold references to the bootstrap provider and its classes will be flushed. From this point onwards only the configured providers, and their algorithms, are used. The load and unload of the bootstrap provider is performed with out user involvement and due to the transient nature of the bootstrap provider user applications should be unaware of its presence.