In the last few years we have seen how increasing computational power of electronic devices triggers the functionality growth of the software that runs on them. The natural consequence is that modern software is no longer single-pieced, it becomes, instead, the composition of autonomous components that run on the shared platform. The examples of such platforms are web browsers (such as Google Chrome), smartphone and smart card operating systems (e.g., Android and Java Card), intelligent vehicle systems or smart homes (usually implemented on OSGi). On one hand, these platforms protect components by isolation, but at the same time, provide methods to share and exchange services. If the components can come from di erent stakeholders, how do we make sure that one's services would only be invoked by one's authorized siblings? In this PhD proposal we illustrate the problems on the example of OSGi platform. We propose to use the security-by-contract methodology (S C) for loading time security veri cation to separate the security from the business logic while controlling access to applications.
metadata. The services layer connects bundles in a dynamic way with a publishnd-bind model for Java objects. As a result, an OSGi platform is expected to be highly dynamic. All pervasive and mash-up applications expect that bundles can be installed, updated or removed at any time. From a security perspective, the possibility of bundle interactions is a threat for bundle owners. Since bundles can contain sensitive data or activate sensitive operations (such as locking doors and windows of somebody's house), it is important to ensure that the security policy of each bundle owner is respected by other bundles. However, such aspects have been only partially investigated.
How do we make sure that one's services are invoked by one's authorized
siblings? A simple solution is to rely on service-to-service authentication to identify
the services and then interleave functional and security logic into bundles, for
example, by using aspect-oriented programming [
Our solution is to use the security-by-contract methodology (S C) [
In the next section we illustrate the problem by introducing a concrete case study for home gateways (x2) and discuss the security issues that the plain OSGi model cannot solve without ad-hoc security codes within each bundle. We then introduce the solution (x3) and conclude in x4 with an overview of the paper. 2
Further we concentrate on OSGi platform, identify the ows of its security mechanisms. However, due to the similarities in the architecture, the problems can be applied to other service platforms (e.g., Android) as well. Due to the paper length constraints we skip the technical description of the OSGi platform and assume the reader has at least a basic familiarity with the service platform architecture.
The Scenario We consider as a case study an OSGi platform deployed as a
service gateway in a smart home. Let us consider Alice, the smart home
resident, and a telecom provider, the owner of the platform. Alice can download
bundles for entertainment (news RSS feeds, media bundles from TV providers)
or even bundles with traditional Internet content (like Facebook or Twitter), as
nowadays new TV sets can be used for all these purposes. The interested reader
can refer to [
Alice, a beginner stock market player, downloads and installs bundle A from provider F SM:com that can provide her with an interface of the stock market operations. This bundle includes service SA that retrieves updates about the stock prices. However, Alice later nds and installs another stock market bundle B from BH:f r provider, that also provides service for prices information retrieval SB and service Sfr that allows Alice to transfer money from her stock market account (registered on BH:f r) to her Happy Farm account on F B:com. Thus Alice also installs Happy Farm bundle F .
The bundle providers want to ensure that their security policies related to bundles and services usage are enforced on the Alice's platform. Their requirements are as follows: FSM.com: Access to SA service is allowed only for bundles signed by F SM:com. BH.fr: Access to SB service is allowed only for bundles signed by BH:f r. Only bundles signed by BH:f r can import the package containing SB. Access to Sfr service can be granted only for bundles signed by F B:com or by BH:f r.
The OSGi platform at Alice's smart home has to ensure that the requirements of each provider are respected. We will next discuss how the OSGi platform can enforce these requirements and why this approach is not satisfactory. We will also demonstrate that there can exist similar requirements of bundle providers that cannot be enforced by the OSGi platform at all.
Security Challenges Let us rst brie y present the relevant OSGi platform
details [
We assume the framework can host multiple third-party bundles, and these bundles can freely register services. The goal of the telecom provider running the platform is to make sure that there are no undesired security or functionality problems among di erent bundles installed by the end user (who most likely does not even 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 unauthorized access to the sensitive data of another bundle (security threat), or a bundle is malfunctioning due to unavailability of a certain service (functionality threat). We now discuss these threats separately in the light our scenario.
A con dentiality attack can be realized by the bundle A of provider F SM:com getting access to the sensitive stock market prices service SB of provider BH:f r.
This might happen if A imports the package containing the service SB de nition, requires the bundle B (thus importing all its exported packages), or tries to get a reference to this service from the Service Registry and then get access to the object referenced.
We now discuss how the current OSGi security management can address this security threat. Import of a package or a require-bundle action can be granted if the requiring bundle has corresponding permissions. Simple reviewing of the manifest le and permissions le of the bundle A can report 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:f r provider, to declare which other bundles are allowed to import its packages.
Package importing can be guarded by the permissions mechanism, as we discussed before. Currently only the platform owner (the telecom provider) can de ne and manage policies in the Conditional Permission Admin policy le. The BH:f r provider might contact the telecom provider to ask him to set the required permissions, or its bundle B, being granted the necessary permissions, can add new permissions to the Conditional Permission Admin policy le. These approaches are organizationally cumbersome and costly, as they require the operator to push the changes to its customers before any downloads of BH:f r bundles, even the customers have no intention of using them.
Service usage is another, more trickier issue. Again, the necessary authorizations for the service usage (more precisely, GET permissions for service retrieval) can be delivered within bundle contracts and incorporated into the policy le of the system. But the invocations of the methods within a service, once the necessary reference is obtained, are not guarded by the permission check, and usually the security checks are placed directly within the service code, thus mixing the security logic with the execution logic.
Another solution, that is traditional for mobile Java-based component systems, could be to ask Alice each time a speci c permission is needed. But Alice is not the owner of the bundles to make such decisions, nor is she interested to do so. Let us consider a more complex scenario now.
Example 1 Alice wants to install the Sims add-on from the EA:com provider. This add-on is packaged into the bundle C and it will provide an integration of the Happy Farm account with her the Sims account. The functional requirement of the EA:com provider is the following: \The bundle C can be installed if and only if the F bundle is available on the platform and provides the Happy Farm service SF .
The requirement in Example 1 means that bundle C can be installed only if
the service SF is already provided on the platform. This requirement prevents
the denial of service by the Sims bundle. The bundles are running on top of a
single JVM, thus the denial of service attack can cause a restart of the whole
system [
Our proposed solution is to adopt the Security-by-Contract that was initially
investigated and implemented by Bielova et al. for mobile Java-based devices [
The S C framework consists of two main components: the ClaimChecker and the PolicyChecker. The veri cation work ow is described on Figure 1.
Informally, the S C process starts when a new bundle B is loaded. The ClaimChecker component then accesses the manifest le, retrieves the information about imported and exported packages and obtains the bundle contract. Then the ClaimChecker reads the permissions.perm le, which contains local bundle permissions, extracts permissions requested by the bundle B and related to services retrieval, packages importing, requirements of bundles, etc., and combines this information into the overall \security claims and needs" of the bundle. Having these claims, the ClaimChecker then analyzes the bytecode of the bundle to verify that the claims match actual code. If the veri cation fails, meaning that the claims are not supported by the code, the bundle is removed from the platform. Otherwise, the PolicyChecker component receives the result from the ClaimChecker and matches it with the security policy of the platform, that aggregates the security policies of all the installed bundles, and with the functional state of the platform (installed bundles, running services, etc.). If the PolicyChecker failed on either of the checks, the bundle is removed from the platform. Otherwise, it is installed and the security policy of the platform is updated by including the security requirements of B.
In terms of technical realization, the S C steps can be integrated with the OSGi framework. The key requirement is getting the correct and up-to date information about the state of the platform and being able to access the received bundle before it is deployed on the platform. The S C framework itself can be a bundle, provided it can access the service registry, the framework policy le, the lifecycle layer and the manifests of the bundles. 4
In this proposal we have identi ed the security problems of some of the Javabased service platforms on the example of OSGi platform. We have presented and idea of solution, which is a Security-by-Contract paradigm for the OSGi platform. We discussed the security and functionality challenges and proposed how to enable the bundle providers with ability to e ectively express their security and functional requirements on the platform.
The main bene ts that the S C approach can bring to service platforms are the following. From the security aspect, the bundle providers can now specify the authorizations for access to their bundles, packages and services. The policies can be updated easily and the update does not require an interaction from the platform owner, an access to the framework policy le or an update of the execution logic of the bundle. For the functionality aspect, the bundle providers have now a more powerful tool for expressing their functional requirements than the requirement/capability model of OSGi. The contracts can express requirements on the current state of the platform (including requirements on the states of the bundles or certain services provision, or absence of the competitor's resources).