Browse Prior Art Database

A mechanism for identifying trusted application modules in a highly dynamic environment Disclosure Number: IPCOM000184207D
Original Publication Date: 2009-Jun-15
Included in the Prior Art Database: 2009-Jun-15
Document File: 3 page(s) / 66K

Publishing Venue



In a modular software system, such as an OSGi framework, modules are sourced from a large variety of locations. Some are available from internal, tightly governed sources, but others are only available insecurely or from a repository over which you have no control. Enforcing security in this situation can be incredibly difficult. This article describes a mechanism by which application developers and deployers can establish trust between modules from a wide variety of sources. The mechanism described does not require that all modules fulfill the same requirements to be trusted, nor does it require that all applications, or the application platform, share trust for the same module.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 41% of the total text.

Page 1 of 3

A mechanism for identifying trusted application modules in a highly dynamic environment

An important part of software security is ensuring that any code to be executed is from a trusted source, and has not been tampered with. There are existing mechanisms that allow the source and integrity of application code to be verified. These mechanisms, however, are inflexible in large, modular systems for several reasons.

Typically a signed application must be deployed as a single unit (e.g. a single jar file). This is completely at odds with modular application design.

The overall content of an application cannot change and still be trusted without uninstalling, re-signing and redeploying the application. This is not dynamic. Typically the list of trusted signers (providers of application code) is shared throughout the whole system. This does not give different applications the flexibility to trust different code providers.

In a modular environment it is likely that some code will be supplied by third parties, potentially from repositories that are not under the control of the Application developer or deployer. In this situation it is vital to establish that the code is provided by a trusted author before using modules provided by these repositories.

    The solution disclosed proposes a mechanism by which applications can establish trust with modules from disparate sources, even if the modules are subsequently updated. It also removes the restriction that all trusted signers must be trusted by all applications.

    OSGi Applications can consist of multiple bundles, these applications can be specified as a list of bundles within specified version ranges. The bundles that make up the application are retrieved from a logical bundle repository, and at any given time there may be a new suitable version of a particular bundle.

    This solution proposes an extension to the existing application specification, such that it contains a list of certificate aliases and is, itself, signed. The aliases contained in the application manifest describe the list of trusted code signers for this application, i.e. the list of trusted certificates. As the application descriptor is also signed, this prevents it from being tampered with.

    Application descriptors within a server should be signed by a certificate trusted by the server, this step ensures that all applications are trusted by the server hosting them.

An example application descriptor is identified below.

Manifest-Version: 1.0
Application-ManifestVersion: 1.0
Application-Name: Blog Application
Application-SymbolicName: Application-Version: 1.0
Application-Content:;version=[1.0.0, 2.0.0),;version=[1.0.0, 1.6.0],;version=[1.0.0,1.2.0] This descriptor can be enhanced in a number of ways:

Manifest-Version: 1.0 Application-ManifestVersion: 1.0