!

DISI!%!Via!Sommarive!14!%!38123!Povo!%!Trento!(Italy)!http://www.disi.unitn.it!!

SECURITY-BY-CONTRACT FOR THE OSGI PLATFORM

Pedro Capelastegui, Olga Gadyatskaya, Fabio Massacci and Anton Philippov January 2012 Technical Report # DISI-12-002 Version 1.0

Security-by-Contract for the OSGi platform

Pedro Capelastegui1, Olga Gadyatskaya2, Fabio Massacci2, and AntonPhilippov2

1pcapelastegui@gmail.com

2 University of Trento, Italy{name.surname} @unitn.it

Abstract. The natural business model of OSGi is dynamic loading andremoval of bundles or services on an OSGi platform. If bundles can comefrom di↵erent stakeholders, how do we make sure that one’s serviceswill only be invoked by the authorized bundles? A simple solution isto interweave functional and security logic within each bundle, but thisdecreases the benefits of using a common platform for service deploymentand is a well-known source of errors. Our solution is to use the Security-by-Contract methodology (S⇥C) for loading time security verification toseparate the security from the business logic while controlling access toapplications. The basic idea is that each bundle has a contract embeddedinto its manifest file, that contains details on functional requirementsand permissions for access by other bundles on the platform. Duringbundle installation the contract is matched with the platform securitypolicy (aggregating the contracts of the installed bundles). We illustratethe S⇥C methodology on a concrete case study for home gateways anddiscuss how it can help to overcome the OSGi security managementshortcomings.

1 Introduction

The Open Services Gateway Initiative (OSGi) framework [3, 4] is one of themost flexible solutions for the deployment of pervasive services in home, o�ce,or automobile environments [13, 17, 26]. OSGi-compatible implementations con-stitute the backbone of many recent proposals for embedded systems [5] or otherindustry-based services [25]. The OSGi services are also the basic building blocksfor service mash-ups extending the classical “smart homes” scenarios to richersettings [21].

In a nutshell, the OSGi framework redefines the modular system of Java byintroducing bundles: JAR files enhanced with specific metadata. The serviceslayer connects bundles in a dynamic way with a publish-find-bind model forJava objects. An OSGi-based system has several advantages over the traditionalJAR modules. First, OSGi provides a robust integrated environment where bun-dles can be published and exported to be used by other bundles. Second, OSGiprovides versioning of bundles for every new deployment and maintains the bun-dle lifecycles. And third, the bundles can be updated dynamically at run timewithout restarting the system and seamlessly to other bundles.

As a result, an OSGi platform is expected to be highly dynamic. All perva-sive and mash-up applications expect that bundles can be installed, updated orremoved at any time depending on business needs.

From a security perspective, the possibility of bundle interactions is a threatfor bundle owners. Since bundles can contain sensitive data or activate sensitiveoperations (such as locking doors and windows of somebody’s house), it is im-portant to ensure that the security policy of each bundle owner is respected byother bundles. However, such aspects have been only partially investigated.

How do we make sure that one’s services are invoked by authorized bundles?A simple solution is to rely on service-to-service authentication to identify theservices and then interleave functional and security logic into bundles, for ex-ample, by using aspect-oriented programming [26]. However, this decreases thebenefits of using a common platform for service deployment and significantlyhinders evolution and dynamicity: any change to the security policy would re-quire redeployment of the bundle (even if its functionalities are unchanged). Viceversa, any changes in the bundle’s code would require redeployment of securityas well.

1.1 The Contribution of this paper

Our solution is to use the Security-by-Contract methodology (S⇥C) [6, 7] forloading time security verification in order to separate security and the businesslogic while achieving a su�cient protection of bundles among themselves.

S⇥C’s basic idea is that each bundle will have a contract embedded into itsmanifest file. The contract contains details on the functional requirements andlists access permissions for other bundles on the platform. During installation ofbundles the contract is extracted and matched with the platform security policyaggregating the contracts of all installed bundles. Thus after the check we canbe sure (under reasonable assumptions) that the incoming bundle respects thesecurity limitations posed by other bundles.

Overall contribution of the paper is twofold. First, we improve the securityof OSGi platform by introducing a way for bundle providers to define theirsecurity policies and enforcing them on the platform. Second, we extend theS⇥C paradigm to a permission-based security system, opening a way for it to beadopted further for other platforms.

In the next section we describe the overall architecture of the S⇥C extensionof the OSGi platform (§2). Then, in order to illustrate the methodology, weintroduce a concrete case study for home gateways (§3) and discuss the securityissues that the plain OSGi model (presented in §4) cannot solve without ad-hocsecurity codes within each bundle (§5). Next, we introduce the platform model(§6), the format of a bundle contract (§7) and the checks that need to be doneto enforce security on the OSGi platform (§8). We further discuss the threatsto validity of this solution (§9) and present a brief overview of of related work(§10. We conclude with evaluation of the proposed solution and plans for futureresearch (§§11-12).

2 The S⇥C Architecture

We assume at least a high-level understanding of the main notions of the OSGiplatform such as bundles (the OSGi components made by developers), services(plain old Java objects connecting bundles in a dynamic fashion by the means ofpublish-find-bind model), lifecycle API (the API to install, start, stop, update,and uninstall bundles) and modules – the layer that defines how a bundle canimport and export code.

The S⇥C framework consists of two main components: the ClaimExtractor andthe PolicyChecker. The verification workflow is described on Figure 1.

Informally, the S⇥C process starts when a new bundle B is loaded. TheClaimExtractor component then accesses the manifest file, retrieves the informa-tion about imported and exported packages and obtains the bundle contract.Then the ClaimExtractor reads the permissions.perm file, which contains localbundle permissions, extracts permissions requested by the bundle B and relatedto services retrieval, packages importing, requirements of bundles, etc., and com-bines this information into the overall “security claims and needs” of the bundle.Then the PolicyChecker component receives the result from the ClaimExtractorand matches it with the security policy of the platform, that aggregates the se-curity policies of all the installed bundles, and with the functional state of theplatform (installed bundles, running services, etc.). If the PolicyChecker failedon either of the checks, the bundle is removed from the platform. Otherwise, itis installed and the security policy of the platform is updated by including thesecurity requirements of B.

Fig. 1. The S⇥C Workflow

When a bundle is removed we do not run the S⇥C checks, as only the func-tional requirements can fail in this case and a bundle is free to define its actionsin case its functional requirements will fail in the future. It will receive syn-chronously a notification about the removal of a necessary service or an arrivalof a rival bundle, and it’s up to the bundle provider to decide what to do.

The S⇥C checks will be run in case of bundle code update or bundle pol-icy update. These checks, however, are variations of the installation scenario.

Thus in the sequel we will focus on only the installation scenario as the mostrepresentative one.

In terms of technical realization, the S⇥C steps can be easily integrated withthe OSGi framework. The key requirement is getting the correct and up-to dateinformation about the state of the platform and being able to access the receivedbundle before it is deployed on the platform. The S⇥C framework itself can be abundle, provided it can access the service registry, the framework policy file, thelifecycle layer, etc.) and the manifest file and permissions.perm file of bundlesbeing loaded on the platform.

3 The Running Example

We consider as a case study, shared by an OSGi Alliance 3 member Telefonica4,an OSGi platform deployed as a service gateway in a smart home. Let us considerAlice, the smart home resident, that can install untrusted bundles on the OSGiplatform. The owner of the platform is a telecom provider, that wants to avoidsecurity problems, as otherwise Alice will call the provider hotline and mightconsider it liable for any problem.

Alice can download bundles for entertainment (news RSS feeds, media bun-dles from TV providers) or even bundles with traditional Internet content (likeFacebook or Twitter), as nowadays new TV sets can be used for all these pur-poses. The interested reader can refer to [9] for more details on the news feedscenario. In the running scenario we have used fictional names, but they give anidea of realistic bundle interactions and possible policies regarding these inter-actions.

Alice, a beginner stock market player, downloads and installs ’com.fancystock-market.FancyStockMarketBundle’ that can provide her with an interface withthe stock market operations. This bundle includes service ’com.fancystockmarket.-StockPricesService’ that retrieves updates about the stock prices. However, Al-ice later finds another stock market interface provider and installs ’fr.bourse-hints.BourseStockMarketBundle’, that also provides service for prices informa-tion retrieval ’fr.bourse-hints.PricesInfoService’ and service ’fr.bourse-hints.Bo-urseHappyFarmerService’ that allows Alice to transfer money from her stockmarket account (registered on bourse-hints.fr) to her Happy Farm account onfacebook.com. Thus Alice also installs ’com.facebook.HappyFarmBundle’.

The bundle providers want to ensure that their security policies related tobundles and services usage are enforced on the Alice’s platform. Their require-ments are listed in Table 1. We see that for stock prices services usage theproviders fancystockmarket.com and bourse-hints.fr want to deploy a classicsame origin policy, as they do not want to share the sensitive stock prices infor-mation. Instead, for its Happy Farm service the bourse-hints.fr provider wantsto share also with bundles coming from the facebook.com provider.

3 http://www.osgi.org/4 http://www.telefonica.com/

Provider Requirement

fancystock- Access to ’com.fancystockmarket.StockPricesService’ is allowed onlyfor bundles signed by

market.com fancystockmarket.com providerbourse-hints.fr Access to ’fr.bourse-hints.PricesInfoService’ is allowed only for bun-

dles signed by bourse-hints.fr providerbourse-hints.fr Only bundles signed by bourse-hints.fr can import the package con-

taining ’fr.bourse-hints.PricesInfoService’bourse-hints.fr Access to ’fr.bourse-hints.BourseHappyFarmerService’ service can be

granted only for bundles signedby facebook.com or by bourse-hints.fr

facebook.com -Table 1. The running example policies

In the sequel we will refer to the fancystockmarket.com provider as FSM.comprovider, to the ’com.fancystockmarket.- FancyStockMarketBundle’ as bundleA and to the service ’com.fancystockmarket.StockPricesService’ as service SA.Correspondingly, we will denote bourse-hints.fr provider as BH.fr provider, itsbundle ’fr.bourse-hints.BourseStockMarketBundle’ we will denote as bundle B,service ’fr.bourse-hints.PricesInfo- Service’ we will denote as service SB and ser-vice ’fr.bourse-hints.BourseHappyFarmerService’ we will denote as Sfr. Finally,facebook.com we will refer to as FB.com provider, Facebook bundle will be re-ferred to as F bundle, package ’com.facebook.FarmerPackage’ as PF and service’com.facebook.- FarmerService’ as SF .

The OSGi platform at Alice’s smart home has to ensure that the requirementsof each provider are respected. We will discuss in Section 5 how the OSGi plat-form itself can enforce the requirements of the providers FSM.com and BH.frand why this approach is not satisfactory. We will also demonstrate that therecan exist similar requirements of bundle providers that cannot be enforced bythe OSGi platform at all. However, prior to this discussion we need to introducemore details about the OSGi technology itself.

4 An OSGi Technology Overview

The current section is dedicated to the OSGi platform (v. 4.3 [3]) details relevantto the running scenario.

An OSGi bundle is a JAR file enhanced by specific metadata. A bundle in-cludes the manifest.mf file (manifest file in the sequel) containing the necessaryOSGi metadata: the symbolic name of the bundle, its version, the dependenciesand the provided resources. Some packages of a bundle can be exported (acces-sible for other bundles on the platform). A bundle also typically includes anactivator (used for bootstrapping when the bundle is started) and a file withsecurity permissions requested by the developer).

The OSGi specification defines manifest headers used by developers to de-scribe a bundle, some of them are:

• Export-Package contains a list of exported packages.• Import-Package declares the imported packages.• Provided-Capability specifies a set of provided capabilities.• Require-Bundle specifies that all exported packages from another bundle

must be imported.The OSGi system maintains the evolving lifecycles of the bundles. The bundle

must first be installed. It can be resolved when all its dependencies are resolved.In the Resolved state, the bundle activator can be launched in order to configurethe bundle and possibly launch some services. Figure 2 presents the lifecycle ofa bundle, that is managed by the OSGi platform in a centralized fashion.

Fig. 2. Lifecycle of a bundle

Bundles can depend on external entities (it can require other bundles, an exe-cution environment, a specific library, etc.). Once a bundle is started, it assumesthat those dependencies were resolved. Bundles can express their dependenciesas requirements on capabilities that are provided by the runtime environment orother bundles.

Capabilities are attribute sets in a specific namespace and requirements arefilter expressions that assert the attributes of the capabilities. A requirementis satisfied when there is at least one capability that matches the filter. Therequirements are transitive: bundles can only provide their capabilities whentheir own requirements are satisfied. The Require-Capability and Provided-

Capability headers are manifest headers that declare generic requirements andcapabilities. The OSGi framework can match the requirements to capabilities ofother bundles in the resolving phase.

Example 41 Let us consider the bundle A from Section 3. We can assume thatthis bundle exports the package ’com.fancystockmarket.FancyStockMarketPackage’(version 1.0) and requires the OSGi execution environment with a version greateror equal 4.0. This bundle then has the following headers in its manifest file:• Bundle-SymbolicName: com.fancystockmarket.FancyStock- MarketBundle;

• Export-Package: com.fancystockmarket.FancyStockMarket- Package; ver-sion = 1.0;• Require-Capability: osgi.ee; filter=“(version ¿= 4.0).”

The require/provide capabilities mechanism is very complex, but it has itsdrawbacks. One of them is that the bundles themselves declare what they aregoing to provide to the platform. In fact, it may happen that a bundle declarescertain functionality (for example, provision of a certain API), but does notprovide it in reality. Consequently, some bundles can be resolved at a momentwhen their needs are not satisfied, potentially crashing the framework.

Bundles can interact through two complementary mechanisms: the exportand import of packages and the service registration/lookup facility. A service isa normal Java object that is registered under a Java interface with the serviceregistry. Bundles can register services and search for them, or receive notificationswhen their registration state changes.

A service interface is the specification of the service’s public methods. A de-veloper creates a service by implementing its service interface and registering itwith the framework service registry. When requesting a service from the frame-work, a bundle specifies the name of the service interface and, optionally, a filterto narrow the search. In response, the framework first sends ServiceReferenceobjects of the services that satisfy the search filter. The actual service objectcan then be acquired by passing the specific ServiceReference to the platform,providing the caller has the ServicePermission[ServiceReference, GET] permission.

Security of the OSGi platform is based on the Java 2 security architecture.Each bundle is associated with a set of permissions, that are queried at run-time. The OSGi platform can authenticate code by download location or bysigner (digital signature). The Conditional Permission Admin service manages thepermissions based on a comprehensive conditional model.

A bundle has local permissions defined by the developer in the filepermissions.perm (permissions file in the sequel). These are the actual detailedpermissions needed by this bundle to operate. A framework also provides anadministrative service to associate a set of system permissions with a bundle.The bundle’s e↵ective permissions are the intersection of the local permissionsand the system permissions. That is, a bundle cannot get more permissionsthan its local permissions set. Thus a bundle developer can limit the possiblepermissions of a bundle, but she cannot require a minimum set of necessarypermissions to be granted and she cannot directly influence the set of systempermissions granted to the bundle.

The OSGi specification defines ServicePermission, BundlePermission andPackagePermission. These are used to provide access to getting or registering aservice, importing or exporting bundles and packages respectively.

Example 42 Bundle A from example 41 needs the following permissions (amongothers):• ServicePermission[com.fancystockmarket.StockPricesService,

REGISTER] to be able to register the service;

• PackagePermission[com.fancystockmarket.FancyStockMarket�Package,EXPORTONLY] to be able to export the package.

5 Security Challenges

We assume the framework can host multiple third-party bundles, and these bun-dles can freely register services. The goal of the telecom provider running theplatform is to make sure that there are no security or functionality problemsamong di↵erent bundles installed by the end user (who most likely does noteven know what is a bundle and just sees the web interfaces of the services).Thus a threat scenario under investigation is a case when a bundle gains unau-thorized access to the sensitive data of another bundle (security threat), or abundle is malfunctioning due to unavailability of a certain service (functional-ity threat). We now discuss these threats separately in the light of the runningexample from Section 3.

A confidentiality attack can be realized by the bundleA of provider FSM.comgetting access to the sensitive stock market prices service SB of provider BH.fr.This might happen if A imports the package containing the service SB definition,requires the bundle B (thus importing all its exported packages), or tries to geta reference to this service from the Service Registry and then get access to theobject referenced.

The current OSGi security management suggests to address this securitythreat using the permissions system. Import of a package or a require-bundleaction can be granted if the requiring bundle has corresponding permissions.Simple reviewing of the manifest file and permissions file of the bundle A canreport about a (potential) attempt to interact with the bundle B. However,there is no convenient and simple way for the owner of the bundle B, the BH.frprovider, to declare which other bundles are allowed to import its packages.

Package importing can be guarded by the permissions mechanism, as we dis-cussed before. Currently only the platform owner (the telecom provider) candefine and manage policies in the ConditionalPermissionAdmin service policy file.The BH.fr provider might contact the telecom provider to ask him to set therequired permissions, or its bundle B, being granted the necessary permissions,can add new permissions to the ConditionalPermissionAdmin policy file. Theseapproaches are organizationally cumbersome and costly, as they require the op-erator to push the changes to its customers before any downloads of BH.fr bun-dles, even if some customers have no intention of using them. The S⇥C paradigm,on the other hand, enables the bundle providers with a way to specify in thebundle contracts the necessary authorizations. The framework can then collectthese authorizations from the bundles and incorporate them in the S⇥C policyon demand.

Service usage is more tricky though. Again, the necessary authorizations forthe service usage (more precisely, GET permissions for service retrieval) can bedelivered within bundle contracts and incorporated into the policy file of thesystem. But the invocations of the methods within a service, once the necessary

reference is obtained, are not guarded by the permission check, and usuallythe security checks are placed directly within the service code, thus mixing thesecurity logic with the execution logic.

Another solution, that is traditional for mobile Java-based component sys-tems, could be to ask Alice each time a specific permission is needed. But Aliceis not the owner of the bundles to make such decisions, nor is she interested todo so.

Let us now consider a more complex scenario.

Example 51 Alice wants to install the Sims add-on from the thesims.ea.comprovider. This add-on is packaged into the bundle ’com.ea.thesims.FarmerSims-Bundle’ and it will provide an integration of the Happy Farm account with herthe Sims account. The functional requirement of the thesims.ea.com provider isthe following: “The bundle ’com.ea.thesims.FarmerSimsBundle’ can be installedif and only if the Facebook bundle is available on the platform and provides theservice ’com.facebook.FarmerService”’.

The requirement in Example 51 means that ’com.ea.thesims.FarmerSims-Bundle’ can be installed only if the service ’com.- facebook.FarmerService’ isalready provided on the platform. This requirement prevents the denial of serviceby the Sims bundle. The bundles are running on top of a single JVM, thus thedenial of service attack can cause a restart of the whole system [12].

This functional requirement is, in fact, unsupported by the current OSGispecification. Requirements/capabilities model cannot provide guarantees on theprovided services (except that their definition exists on the platform). We willfurther demonstrate how this kind of policy can be enforced by the Security-by-Contract mechanisms, and how the requirements from the running example inSection 3 can be enforced in a flexible and e�cient manner.

Further we will refer to thesims.ea.com provider as EA.com and ’com.ea.-thesims.FarmerSimsBundle’ as C bundle.

6 The OSGi Platform Formal Model

We start with the formal model of the OSGi platform. The entities on thisplatform are bundles and services, but the model also takes into account thelifecycle of bundles, as it is an explicit part of the OSGi platform.

Let �B be a domain of symbolic bundle names, �S be a domain of symbolicservice names and �P be a symbolic domain of package names. Let also �L bea domain of location strings for the bundles and �Sign be a domain of bundlesigners names. We also define a set of local permissions requested by each bundlein its permissions file by Permissionsbundle, where each single permission perm isa pair hTarget, Actioni.

Definition 1 (Bundle). A bundle B is a tuple hB, state(B), exportsB, importsB,PermissionsB, LocationB, SignerBi, where B 2 �B, state(B) 2 {Installed,Resolved,Starting,Active, Stopping} is the current state in which the bundle resides at the

moment, exportsB ✓ �P and importsB ✓ �P are the sets of packages exportedand imported by B correspondingly, PermissionsB is the set of local permissionsof bundle B, LocationB is the download location and SignerB is the signer (theprovider) of the bundle B.

Uninstalled state is not considered, as the bundle is not functioning in this stateand cannot be transferred to other states, so this state is equivalent to deletionof a bundle.

We define an “is defined in” relation ⇧ for packages, bundles and serviceinterfaces. Let B be a bundle, S be a service interface and P be a package. Wewill denote by P ⇧B the fact that P is a package defined in the bundle B and byS⇧P the fact that the service interface S is defined in the package P . For defininglocations of bundles we define a ` relation (“comes from”), we will denote asL ` B the fact that bundle B comes from location L 2 �L. Also for locations wecan define a notion of location inclusion, we will denote as L1 ✓ L2 if the stringlocation L1 includes the string location L2 as a prefix (without wildcards).

Example 61 Let us consider the bundle A discussed in Examples 41–42. Thisbundle can be represented as a tuple hA, state(A), exportsA, importsA,PermissionsA,LocationA, SignerAi, where state(A) depends on the current state, for example,we can assume that this bundle was resolved successfully, as it does not in-clude any external dependencies, and currently state(A) = Active. exportsA ={

0com.fancystock �market.FancyStockMarketPackage0}, importsA = ;,LocationA = ’https://fancystockmarket.com/bundle’,SignerA = ’fancystockmarket.com’. Relevant permissions are listed in Exam-ple 42, so we do not repeat them.

Definition 2 (OSGi Platform). The platform ⇥ is a tuple hB,S,Ri where B

is a set of bundles on the platform, S ✓ �S is a set of services on the platform,and R✓ B ⇥ S is a service provision relation such that for each service S 2 S

there exists only one bundle B 2 B such that the pair (B,S) 2 R, state(B) 2

{Active, Starting, Stopping} and S ⇧ P such that P ⇧B and P 2 exportsB.

Thus, in the model we consider that a service can be provided only by abundle in an appropriate state that exports a package containing the definitionof this service. We will denote the fact that bundle B can provide service S(exists package P such that S ⇧ P and P 2 exportsB) as S@B.

We want to ensure that bundles interact on the platform in compliance withthe pre-defined security policies set by the bundle owners. Thus we start with thedefinition of bundle interaction. Informally, two bundles interact if one of themimports an exported package from another, or consumes a service provided bythe other bundle.

Definition 3 (Bundle Interaction). Let B1, B2 2 B. We say that B1 inter-acts with B2, denoted B1 ./ B2 if at least one of the following conditions issatisfied:• Exists P 2 exportsB1 \ importsB2 such that P ⇧ B1 – there exists a package

exported by B1 and imported by B2;• Exists a local permission perm= hGET, Si 2 PermissionsB2 where S is a ser-

vice such that exists a package P : S ⇧ P and P 2 exportsB1 – there exists a localpermission of bundle B2 to get a service reference from bundle B1.

This definition captures a potential direct control flow among bundles.Functionality guarantees on the OSGi platform can vary. An interesting sce-

nario was discussed in Example 51, where a bundle wants to have some functionalrequirements fulfilled prior to be loaded. The capabilities approach currently ex-plored on the OSGi platforms is purely static and declarative. We want to en-hance it with the dynamics of evolving platforms and with the guarantees givenby the framework itself rather than by (potentially untrusted) bundles.

In Example 51, the C bundle wants to be installed on the platform only ifa specific service is already provided there. While the presence of the serviceinterface definition can be (limitedly) ensured by the capabilities approach, onlythe Framework (the platform in our model) itself can assure that the service isindeed provided, or a certain bundle is in a desired state, or that a competitor’sbundle is not installed at all. If later, when the bundle will already be installed,the platform will evolve such that the desired service will be unregistered or anundesired bundle appear, the bundle can be notified about it through the eventsystem and take the actions it needs to protect itself (be removed, stop, notifythe provider, etc.).

There is also another interesting problem that can be considered. The pri-mary purpose of the requirement-capabilities model is to provide an explicitassertion about the environment before a bundle becomes active and its codestarts to run. This prevents bundles that cannot run because they are not suit-able for a given environment from becoming active, or even installed, when thisheader is used by a management system. The S⇥C framework can become themanagement system that will assure bundles they will never enter even theInstalled state on a platform that is not suitable for them.

7 Contracts and Policy

The claim of a bundle (su�cient to cover the security and functionality issuesdiscussed above) can be easily extracted from the bundle’s manifest file andpermissions file. Thus the ClaimExtractor component duties will be to extract thisinformation. The policy of a bundle is a new component specified in the contractthat requires a permission notation and a notation for functional requirements.

Definition 4. Let B be a bundle. The ContractB is a tuple hsec.rulesB, func.rulesBi,such that:– sec.rulesB is a set of permissions of the form hAction, Target,Authorized entityi, that specifies the security policy on the usage of B’s pack-ages and services, where• Action 2 {IMPORT,GET};

• Target 2S

P⇧BP [

SS@B

S;

• Authorized entity 2 �B [�L [�Sign;– func.rulesB is a set of functional requirements of B of the formhDesired state, F lag, Statei, that specifies the requests of the bundle for func-tionality available on the platform, where• Desired state 2 {Present,Not present};• Flag 2 {Bundle, Package, Service};• State di↵ers in the following fashion:

• Flag = Bundle, then State 2 {Installed,Resolved,Starting,Active, Stopping};• Flag = Package, then State 2 {Present, Exported};• Flag = Service, then State 2 {Present, Provided};

Using the above notations bundles can express various security and functionalrequirements on other bundles on the platform. Bundles can be installed on theplatform if and only if all their security and functional requirements are satisfiedand their behavior is compliant with the policies of all other bundles on theplatform.

We propose the bundle contract to be delivered within its manifest file byusing the possibility to define new manifest file headers in the common headersyntax. The newly defined headers processed by the S⇥C manifest file parser (theClaimExtractor), are sxc-secrules and sxc-funcrules. The first header specifiesthe bundle’s sec.rules separated by commas (elements of permissions are sepa-rated by colons). The second header denotes the bundle’s func.rules separatedby commas (elements of requirements are separated by colons).

The security policy of the platform is defined as follows.

Definition 5 (Security Policy of the Platform). For a platform ⇥ its se-curity policy Policy⇥=

SB2B

sec.rulesB

Example 71 Let us consider the running example from Section 3. The bundlesA, B and F are installed on the platform. The security policy Policy⇥ of theAlice’s platform equals to {sec.rulesA, sec.rulesB, sec.rulesF}.

The contracts of the bundles can be derived from the requirements listed in Ta-ble 1. Thus, sec.rulesF = {;}. sec.rulesA = {hGET,0 com.fancystockmarket.Stock�PricesService0,0 fancystockmarket.com0

i}.sec.rulesB = {hGET,0 fr.bourse�hints.PricesInfoService0,0 bourse�hints.fr0i,hIMPORT,0 fr.bourse� hintsPricesInfoPackage0,0 bourse� hints.fr0i,hGET,0 fr.bourse� hints.�HappyFarmerService0,0 bourse� hints.fr0i,hGET,0 fr.bourse� hints.HappyFarmerService0,0 facebook.com0

i}

For a platform ⇥ its functional state is at any given moment of time definedby the platform itself: the installed bundles and provided services.

Case Check

B imports a package P of A hIMPORT, P,Bi 2 sec.rulesAB gets a service S registered by A hGET, S,Bi 2 sec.rulesAB requires a bundle A to be present on theplatform in

exists bundle A 2 B such thatstate(A)=Active

Active state:hPresent,Bundle, A,Activei 2 func.rulesBB requires a package P to be exported onthe platform:

exists bundle A 2 B such that P ⇧ A andP 2 exportsA

hPresent, Package, P,Exportedi 2func.rulesBB requires a service S not to be providedon the platform:

For all bundles A 2 B there is no (A,S) 2R

hNot present, Service, S, ProvidediTable 2. Checks to be executed by the PolicyChecker

8 The S⇥C Checks

Definition 6. Let ⇥ be an OSGi platform and B is a loaded bundle. We say ⇥can host B securely if and only if the following conditions are satisfied:

• Stable Security. For all bundles A 2 B if A ./ B then a correspondingpermission for B exists in sec.rulesA, and if B ./ A then a corresponding per-mission for A exists in sec.rulesB.• Stable Functionality. All functional requirements described in func.rulesB

are satisfied by ⇥.

We note that the stable functionality property may not hold for some other bun-dle A immediately after the installation of bundle B on the platform. However,as we have discussed above, A will be notified about the situation and can takeappropriate actions.

Table 2 lists some of the checks that are to be executed by the PolicyCheckerin each case (due to the lack of space we are not able to list all the checks).

It can be easily demonstrated (proof by cases) that if the necessary checksfor a new bundle B are performed by the S⇥C framework, then the platform canhost B securely.

Table 3 contains the sources of information for the components. We cannote here that the permissions file could be a weak source of information, asit may only require AllPermission, letting the system to define the upper boundof permissions for the bundle. This problem can be solved by awareness of thedevelopers that their bundles will be rejected if the required permissions will betoo demanding.

Bundle interactions and functional requirements can give rise to conflict sit-uations.

Example 81 Let us consider again the running example. Let the C (The Sims)bundle from EA.com provider be installed and running. Then Alice might de-cide that she wastes too much time playing while her career as a stock market

Case Source of Information

B imports package P of A The manifest file of B, the permissions fileof B

B gets service S registered by A the permissions file of BB requires bundle A to be present on theplatform in Active state

The platform maintains the bundles andtheir states

B requires package P to be exported onthe platform

The platform identifies the existing pack-ages

B requires service S not to be provided onthe platform

The service registry maintains the pro-vided services

Table 3. Sources of information for the S⇥C Framework

trader does not take o↵. Alice wants to remove the Facebook bundle from theplatform. But the C bundle has specified the service from this bundle running onthe platform as its functional requirement. If the EA.com provider was careless,the removal of the Facebook bundle can cause the C bundle to malfunction oreven the framework to restart.

The choice in this situation is the following: either to remove the Facebookbundle and expect that C bundle can crash, or to forbid the removal of theFacebook bundle. In both cases the consequences are unpredictable. The situa-tion could be improved if the Conflict Resolution component would be providedwithin the S⇥C framework. The Conflict Resolution component can take deci-sions in complex situations depending on the contents of the framework policyfile (some bundles may have more permissions than other do), and the systempolicy specified for such situations.

9 Threats to Validity

Let us now discuss under which assumptions the S⇥C model works. We do notconsider the versioning in the model explicitly. Being an important feature of theOSGi platform itself, the bundle version in the model is folded into the bundlename. For the future work, we intend to introduce the versions explicitly forricher expressiveness of the contracts.

Authentication threats and bundle impersonalization are not treated in themodel, as we rely on the correct platform implementation with reliable authenti-cation mechanisms. Thus we identify entities in the model by their fully-qualifiedsymbolic names, considering the names of providers, bundles, packages and ser-vices to be unique.

Several features of the latest OSGi specification are not discussed in thecurrent paper. These are, for instance, the remote service provision and servicefactories, fragment or extension bundles and library bundles (ones that cannotbe activated). Some of these features can be introduced easily in the model(like library bundles), and some of them are not related directly to the runningexample scenarios. We also did not consider delegation of permissions, assuming

each bundle provider acts on her own behalf, and we did not consider the scenariowhen a single service interface is registered as a service by multiple bundles, asthis scenario is not related to the identified threats. Thus we expect that everybundle can register as a service only the service interfaces defined in its ownpackages.

The OSGi platform, besides the bundle lifecycles, maintains also the frame-work lifecycle, which is not a part of our platform model. We do not treat theframework restarts in the model, as they are not related to the considered at-tacks.

10 Related Work

Though the OSGi technology is gaining popularity today, there are not so manypapers dedicated to the OSGi security. Moreover, these papers are not applicableto the scenarios and threats we considered.

Some research on security of OSGi concerns prevention of attacks on theOSGi platform itself (e.g., system resources modification or denial-of-serviceattacks) [11, 12, 14, 24]. A number of works is dedicated to improving the au-thentication mechanism of OSGi [16, 18, 19]. Ahn et al. [1] apply RBAC to theOSGi-based smart home environments, enabling the smart home residents withaccess rights to di↵erent facilities. Royon et al. [28] suggest isolation of bundlesfrom di↵erent vendors by creating a virtual service gateway for every vendor andthe core service gateway that manages them.

The proposal by Parrend and Frenot [23] on installation time verificationfor the OSGi bundles is the closest to our current work. The authors advo-cate the installation time static analysis of bundle code that could replace thetime-consuming run-time checks for given permissions. Their Component-basedAccess Control (CBAC) mechanism allows to parse the bytecode of the loadedbundle and check that all the sensitive methods it invokes are allowed. Thetesting of the CBAC tool concluded that the overhead of the installation timeverification is insignificant in comparison with the run-time checks. However,the drawbacks of the approach are the same as were concluded for the OSGiframework – the bundle providers are still not entitled to defining their ownpolicies.

Phung and Sands [26] investigate an application of inlined reference moni-toring to the OSGi platforms using an aspect-oriented programming languageAspectJ. The monitors they have developed can enforce history-based securitypolicies, but the needs of the bundle providers to define their own policies werenot taken into account.

There are a number of permission-based security frameworks for service plat-forms outside of the OSGi community (namely, the ones developed for Android).We can mention the work of Enck et el. [8] on the loading time mobile codecertification for Android. The Kirin tool developed by the authors analyzes per-missions requested by the applications and basing on a set of security rules isable to warn the users about dangers of certain applications. The creation of

such security rules is left for the user, although it is not a trivial task. Moreover,the Kirin policies are static and applied in the same manner for all applications,while our system updates the policy with respect to the applications present onthe platform and the security rules are the ones relevant for each application.

Reddy et al. [27] argue that current permission model of Android, which isfocused on resources being used, is too broad and introduce application-centricpermissions, that are more specific and restrictive (e.g., ”access to the specificURL”, ”use camera only for barcode scan”). They develop a number of suchpermissions and a prototype that rewrites applications so that they will usenew permissions. Similar to that, Nauman and Khan [20] argue that currentpermission model is too coarse-grained and inflexible. They present Apex, asystem that supports specification of more fine-grained access control policies forresources (e.g., ”only send 5 sms per day”), and also gives users the freedom tochoose which permissions to grant to application instead of all-or-nothing defaultapproach. While strengthening the security of the framework, this approachrelies on the run-time enforcement that can produce significant computationaloverhead. Moreover, the decisions for policy making, in contrast to our approach,are left for the user and can result in non-functioning software. The needs ofthe Android applications to be able to regulate how they interact with otherapplications were advocated by Ongtang et al. [22]. They have proposed Saint –an extension of the Android platform that governs installation time permissionassignment and controls the run-time use of permissions.

Felt et al. [10] addres so-called confused deputy attack, when a less privilegedapplication accesses confidential services through a more privileged one. Theypropose the IPC Inspection mechanism, that monitors the interactions of appli-cations and reduces the permission set to the intersection of permission sets ofcommunicating applications in case of possible re-delegation attack. Althoughcompletely autonomous, the approach might produce false positives results re-ducing privileges of applications that communicate with benign intentions andthus leaving such applications in a non-functional state. Our approach prevents aconfused deputy attack at the installation time, avoiding the functionality issues.

The Security-by-Contract paradigm that had inspired our proposal was in-vestigated and implemented by Bielova et al. for mobile Java-based devices [6]and by Dragoni et al. for the Java Card platforms [7]. Our current work improvesprevious approaches by defining the S⇥C framework for permission-based sys-tems, thus allowing it to be easily adopted on similar platforms (e.g., Android,Chrome).

The functionality challenges of OSGi are also investigated in the community.The main aspect of functionality that was addressed so far is service availability[2, 29]. Jenson [15] discusses the complexity of the OSGi components dependen-cies resolution with hard and soft constraints.

11 Evaluation

The evaluation of the proposed framework was conducted in collaboration withindustry experts from Telefonica. Two top-level criteria were defined: e↵ectiveusage (which includes applicability and human e↵ort), and specific industrialcriteria (level of automation). Let us now describe each criteria in detail.

Applicability. The OSGi framework presents no obstacles for the implementationof such a system as a bundle.

Human e↵ort. It is expected that the basics of S⇥C methodology will require arelatively low e↵ort for a developer to learn how to create contracts. We estimatethat the deployment of S⇥C will require very little e↵ort for the operator of anetwork of home gateways. Installing a bundle (such as the S⇥C framework) onan OSGi platform is typically a routine task that presents few challenges. TheS⇥C deployment should be transparent to and require no e↵ort from the usersof a gateway, except from perhaps providing confirmation for a system update.

Automation. The S⇥C is expected to work on a fully automated manner, in-specting bundle contracts and enforcing contract policies without need for userinteraction. The generation of contracts, however, cannot be automated in thecurrent framework. As a future development, it would be interesting to find waysto automate contract generation, or at least to have automated tools that guidedevelopers in the process.

Overall, the current S⇥C specification for OSGi platforms looks like a promis-ing starting point, which has some immediate applications as well as some veryinteresting research lines (such as Conflict Resolution) which will need to bestudied in depth. One significant upside of the S⇥C methodology is the fact thatit is optional and backwards compatible, which means that service providers donot need to immediately incorporate contracts into each running service as soonas S⇥C is adopted, but can introduce them gradually as new bundle versions arereleased. This allows careful planning of S⇥C contracts and better distributionof the workload.

12 Conclusions

In this paper we have presented a Security-by-Contract paradigm for the OSGiplatforms. We gave an overview of the OSGi framework and described how thethe OSGi platforms can benefit from the S⇥C approach.

The paper contains the following contributions: (1) discussion on security andfunctionality challenges, and the proposal how to enable the bundle providerswith ability to e↵ectively express their security and functional requirements onthe platform; (2) a formal model of an OSGi platform; (3) the notations forsecurity and functional requirements of bundles; (4) the S⇥C architecture forload-time verification on OSGi.

The main benefits that the S⇥C approach can bring to OSGi platforms arethe following. From the security aspect, the bundle providers can now specifythe authorizations for access to their bundles, packages and services. The policiescan be updated easily and the update does not require an interaction from theplatform owner, an access to the framework policy file or an update of the execu-tion logic of the bundle. For the functionality aspect, the bundle providers havenow a more powerful tool for expressing their functional requirements than therequirement/capability model of OSGi. The contracts can express requirementson the current state of the platform (including requirements on the states of thebundles or certain services provision, or absence of the competitor’s resources).

There are interesting research problems that can be investigated further. Firstof all, the current definition of the bundle interactions is very restricted. The no-tion of bundle interactions can be extended to include actual service methodinvocations or transitive service calls and actual information flow specification.To the best of our knowledge, there are currently no known investigations ofinformation flow among bundles, probably because of the complicated serviceprovision model. For the functionality issues, it would be interesting to extendthe current functional requirements notation to include more complex functionaldependencies descriptions. Finally, the Conflict Resolution component was pro-posed, that can solve conflicts among bundles. The logic of this component couldinclude analysis of consequences of the decision made (e.g., removal of a bundlecauses cascade removal of several other bundles).

Acknowledgements. We would like to thank Telefonica for sharing the casestudy and evaluating our proposal. This work has been partially supported by EUunder grants EU-FP7-FET-IP-Secure Change and EU-FP7-ICT-IP-ANIKETOS.

References

1. G. Ahn, H. Hu, and J. Jin. Security-enhanced OSGi service environments. IEEETran. on Systems, Man, and Cybernetics, Part C: Applications and Reviews,39(5):562 –571, 2009.

2. H. Ahn, H. Oh, and J. Hong. Towards reliable OSGi operating framework andapplications. J. of Inf. Science and Engineering, 23(5):1379, 2007.

3. The OSGi Alliance. OSGi service platform core specification. Version 4.3, 2011.4. B. Balfe. Will Java 8 bring in OSGi?, http://blog.balfes.net/2011/08/09/will-java-

8-bring-in-osgi/.5. P. Belimpasakis, M. Michael, and S. Moloney. The home as a content provider for

mash-ups with external services. In CCNC’2009, pages 1 –5, 2009.6. N. Bielova, N. Dragoni, F. Massacci, K. Naliuka, and I. Siahaan. Matching in

security-by-contract for mobile code. Journal of Logic and Algebraic Programming,78(5):340 – 358, 2009.

7. N. Dragoni, E. Lostal, O. Gadyatskaya, F. Massacci, and F. Paci. A load timePolicy Checker for open multi-application smart cards. In Proc. of POLICY’11,pages 153–156.

8. W. Enck, M. Ongtang, and P. McDaniel. On lightweight mobile phone applicationcertification. In CCS 2009, pages 235–245. ACM, 2009.

9. F. Innerhofer-Oberperfler et al. D2.2: A configuration management process forlifelong adaptable systems. Public deliverable of the Secure Change project, 2011.

10. A.P. Felt, H.J. Wang, Alexander Moshchuk, Steven Hanna, and Erika Chin. Per-mission Re-Delegation: Attacks and Defenses. In 20th Usenix Security Symposium,San Fansisco, CA, 2011.

11. N. Geo↵ray, G. Thomas, B. Folliot, and C. Clement. Towards a new isolationabstraction for OSGi. In IIES ’08, pages 41–45. ACM, 2008.

12. N. Geo↵ray, G. Thomas, G. Muller, P. Parrend, S. Frenot, and B. Folliot. I-JVM:a Java Virtual Machine for Component Isolation in OSGi. In DSN’2009. IEEE,2009.

13. T. Gu, H. Pung, and D. Zhang. Toward an OSGi-based infrastructure for context-aware applications. IEEE Perv. Computing, 3:66–74, 2004.

14. C. Huang, P. Wang, and T. Hou. Advanced OSGi security layer. In AINAW ’07,pages 518–523. IEEE.

15. G. Jenson. Improving component dependency resolution with soft constraints,validation and verification. In ASE ’09, pages 716–720. IEEE, 2009.

16. J. Jeong, D. Shin, and D. Shin. An XML-based single sign-on scheme supportingOSGi framework. In Consumer Electronics, 2005, pages 31 – 32, 2005.

17. C. Lee, D. Nordstedt, and S. Helal. Enabling smart spaces with OSGi. IEEE Perv.Computing, 2(3):89 – 94, 2003.

18. H. Lim, Y. Kim, C. Moon, and D. Baik. Bundle authentication and authorizationusing XML security in the OSGi service platform. ICIS ’05, pages 502–507.

19. C. Moon and D. Park. A user authentication model for the OSGi service platform.In Systems Modeling and Simulation: Theory and Applications, LNCS 3398, pages495–504. 2005.

20. M. Nauman and S. Khan. Design and Implementation of a Fine-grained ResourceUsage Model for the Android Platform. In IJAIT, 2010.

21. A. Ngu, M. Carlson, Q. Sheng, and H. Paik. Semantic-based mashup of compositeapplications. IEEE Tran. on Services Computing, 99:2–15, 2010.

22. M. Ongtang, S. McLaughlin, W. Enck, and P. McDaniel. Semantically richapplication-centric security in Android. In Proceedings of ACSAC 2009, pages340–349, 2009.

23. P. Parrend and S. Frenot. Component-based access control: Secure software compo-sition through static analysis. In Software Composition, LNCS 4954, pages 68–83.Springer, 2008.

24. P. Parrend and S. Frenot. Security benchmarks of OSGi platforms: toward hard-ened OSGi. Software Practice & Experience, 39:471–499, 2009.

25. P. Patrick. System and method for an infrastructure that rnables provisioning ofdynamic business applications. Patent US 2009/0249287 A1, 2009.

26. P. Phung and D. Sands. Security policy enforcement in the OSGi framework usingaspect-oriented programming. In COMPSAC’2008, pages 1076–1082, 2008.

27. N. Reddy, J. Jeon, J.A. Vaughan, T. Millstein, and J.S. Foster. Application-centricsecurity policies on unmodified Android. Technical Report 110017, University ofCalifornia, Los Angeles, 2011.

28. Y. Royon, S. Frenot, and F. Le Mouel. Virtualization of service gateways in multi-provider environments. In Component-Based Software Engineering, LNCS 4063,pages 385–392. Springer, 2006.

29. J. Thomsen. OSGi-based gateway replication. In IADIS ACC’2006, pages 123–129.