Table of Contents

Security-by-Contract for Mobiles and Smart Cards

Among the research topics of the Security Group we focus here on checking that an application satisfies a security property by running a checker on a mobile phone or even smaller devices. It looks like a doomed enterprise, as everybody knows that static analyzers are slow, memory-hungry and utterly useless for anything but off-line verification of specifications (rarely code). However, we were able to achieve a lot.

Our idea, dubbed the Security-by-Contract approach, is that a checker could verify on the fly whether an application would respect the security policy of a mobile phone application at download time, e.g. you could forbid the possibility of sending silent SMSs or making phone calls to premium numbers. If the application didn’t meet your constraints you would inoculate it with your policy monitoring algorithm. In this way the phone should not trust anybody, no market place, no security ratings, etc. It could just trust itself. Of course you always have the Android's alternative of having the user clicking yes on accepting a Manifest that she doesn't understand, and where the guidelines for developers are to ask all permissions possible, even if you don't need them.

Themes

Within the main stream project we covered a number of themes.

In 2006 in the S3MS project we proved it worked on many different mobile phones (Java and .NET) equipped with the system. It was the start of a long standing collaboration with Frank Piessens from KUL.

Recently in the framework of the SECURECHANGE project we were able to push the envelope even further: we could run the verification technique over a smart card by meeting the tough requirements set forth by Gemalto, one of the leading companies in the field. This might be a possible road for the deployment of open, multi-applications smart cards (one of the use cases is a SIM card open for over-the-air application loading).

A short description of the embedded checker for smart cards can be found here: (Whitepaper PDF, Dedicated website). In a nutshell, the checker parses the loaded bytecode and infers the calls to shared services of other applications on card. Each application declares its own access control policy specifying which are the authorized clients per each provided service. On the card this policy is matched against the code of the existing applets; while the loaded code is evaluated with respect to the policies of the existing applets. In this way we ensure already at load time that only authorized clients will be able to invoke the sensitive services. The standard Java Card approach to enforce these kinds of policies is embedding them directly into the application code, what hinders the future application updates and introduces the run-time checking overhead.

The next figure summarizes the load time checking architecture (the white items belong to the standard Java Card architecture, the gray items are introduced by the SxC approach). Our solution is fully backward-compatible with the existing Java Card platforms and requires only minimal changes to the platform Installer and Loader components.

The SxC architecture for load time checks on Java Card

The SxC idea was also applied to multi-tenant OSGi platforms. An application contract (implemented on OSGi as a part of the manifest) was used to enable declarative policies for bundle interactions. We used as a case study a smart home scenario generously shared by Telefonica. More details of our proposal can be found here: SxC for OSGi.

Currently we are researching how to apply the load time checks on Android and other novel mobile platforms. The load time checks are appropriate for mobile platforms: the users typically expect that installation of an app will take some time, while they will not tolerate the delays introduced by run-time monitoring in the execution of their favorite apps. In the same time, during load time we can already effectively disable some vulnerabilities in the app code, such as reducing the number of permissions granted to the app to the permissions actually required in the code.

People

The following is a list a people that has been involved in the project at some point in time.

Projects

This activity was supported by a number of projects

Talks and Tutorials

Publications

SxC for Java Card:

SxC for OSGi:

SxC for Mobile Phones:

Software