Innovations in OSGi

How to prevent patent applications

RFC 73 Introduces new IP

• RFC 73 Signing and Permission Admin

• New security mechanisms for the Framework

• Stumbled on a very innovative idea to handle permissions on a Service Platform that could have wide implications

Traditional Model

Key

Certificate

Signature

code

code

Certificate

Signature

code

Policy

Developer Signer DeployerI have a good bundle!

I trust the guy who wrote this

bundle

I will limit the

permissions

trusttrust

Implicitly trusts thesigner-developerrelation

Traditional Model• The Developer designs the code that requires a set of permissions

to run• Very hard to impossible to calculate these permissions from the

code alone• The signer vouches for the security of the bundle• The signer can only sign the bundle. Meaning it can only say: trust it

completely• The signer is relatively powerless because it cannot say: trust it

within this scope• The operator can only assign a single set of permissions to a signer

in Java 2. – Implies that the permission associated with a signer must be the

superset of all required permissions!– Means that privileged applications and non privileged applications

require different signatures, complicating PKI administration

Traditional ModelDeveloper Signer Deployer

Security scopeSize is proportional to permissions

Java 2 Permissions not good with Zones/Groups

• Windows Permission model is based on zones

• Most important decision is to run an app or not. A running app usually gets all permissions.

• Zones are not useful for Java because permissions are too fine grained. Detaile security configuration information is necessary

Internet

Intranet

Trustedsites

local

RFC 73 Solution

• The developer creates a file with permissions that are needed to run the application

• The signer inspects the file and signs it• The deployer

– Sets the maximum permissions for the signer– It deploys the file with the minimum permissions in the

permission file

• The Framework checks that the bundle will only perform actions that are both:– Permitted by its permission file (vouched for by the signer)– Permitted by the operator, based on its signer (max trust the

deployer has in the signer)

Advantages

• The signer can limit its liability (e.g. it can even sign an untrusted bundle in a very small security scope)

• The signer can use the same certificate for different trust levels, simplifying administration

• The deployer can inspect the permissions file beforehand to see what permissions are needed

• The deployer still limits the maximum security scope an application from a signer can get.

Issues

• This solution is a potential patent, it elegantly solves a very real problem in J2EE, and J2SE applications, maybe even in J2ME

• From an OSGi point of view we should not attempt to obtain patents, but we also do not want to get confronted with patents

• Suggestion is to write an article in the press to establish prior art.