This Page is Still Under Construction

The DBAMP project has ten milestones and related deliverables that reflects the nature of the activities during the respective quarter. Here we provide the nature and experiences of these activities so that the community at large can benefit and extend this work in other related projects.

Following are the list of activities that were performed in DBAMP. They are classified based on the milestones that they enable to achieve.

Analysis of Open Source Mobile Platform

Report on the analysis of Open source mobile platforms was a prerequisite for DBAMP project. The motivation behind this report was to identify and select an open source mobile platform that can be used in research.  This report provides an introduction to the hardware and software components of mobile platforms. It addresses the legal concerns arising from the   use   of   using   Free   Software   and   open   source   code   in   the   project   alongside   some proprietary implementations.

The report closely analyzes basic building blocks (boot loaders, kernels, libraries and middleware   etc.)   of   a   mobile   platform,   which   gives   an   in­-depth understanding of each building block and reveals its importance of the mobile platform for the software integrator.

Further, several development tools, windowing environments, widget toolkits and mobile platforms as a whole are studied to figure out their strengths and weaknesses and compliance to the objective of the research.

  • Hardware
  • boot loader
  • kernel
  • busybox
  • framebuffer and X server
  • Window managers and widget toolkits
  • OS distributions
  • access control
  • toolchain and sdk
  • IPC and application framework
  • Cryptography

Business and technology models for mobile platforms

Consumption oriented nature

Enterprise Mashups

Cloud computing

Service oriented architectures

Browser based platforms

Real world use case for DBAMP

A   Usage   control   enabled   health   care  application   running   on   mobile   devices  consumes   and   shares sensitive clinical data among various clinical departments or authorized bodies both inside the clinical boundaries and outside as well. The information can be shared, distributed or downloaded via different communication channels such as Wireless LAN, Bluetooth, GPRS, EDGE, USB interface etc., from a server or a central repository. The use of the information downloaded from the server is governed by policies   which must be enforced by the UCON enabled application when it uses  (reads, writes   or updates)   the   information.   The   provider   of   the   information   must   be   able   to   verify   that   the   policy accompanying the information was correctly applied and enforced by the remote system.

The UCON enabled health care application must be able to measure its own dynamic behavior while enforcing the policy and also be able to provide proof of its measured behavior to a challenger or provider of the resource (information) in our case the challenger will be server or the central repository. The   downloaded   information   should   not   be  used  or   modified   maliciously   and  must   be   enforced correctly as specified by the provider of the resource and writer of the policy.

Analysis of remote attestation techniques

Most of the existing remote attestation techniques can be categorized into one of the two types either Static or Dynamic. Static remote attestation techniques rely on the signatures or hashes of the binaries in order to determine the state of the software.  As these static remote attestations were developed and deployed in the real world scenarios it soon became evident that these techniques had some awed. Although static remote attestation techniques are relatively simple and can easily be incorporated in existing operating systems to measure and report the sate of
the binaries running on the system.

Firstly static remote attestation techniques ignore the real runtime behavior of an application and assume that if the hash of the binary does not reveal any tampering then the behavior of the application will be trustworthy, this assumption has proved to be the Achilles heel of these remote attestation techniques. Secondly it is dicult to keep track of all of the softwares and their updates that exist out there. Therefore to address the shortcomings of static remote attestation techniques. Dynamic remote attestation techniques were developed whereby the runtime behavior of the application is monitored instead of measuring the binary of an application. Most of the dynamic remote attestation techniques are relatively dicult to integrate
in to the existing operating systems and software applications, mostly because of the reason that their is no clear denition about what exactly is the trustworthy behavior of an application. The benchmarks for trustworthy behavior, dened in the existing remote attestation techniques are either vague or incomplete where only a portion of the activities performed by an application during its execution are monitored.

1. Integrity Measurement Architecture (IMA)
2. Policy Reduced Integrity Measurement Architecture(PRIMA)
3. Property based Attestation
4. Semantic Remote Attestation
5. Remote attestation on program execution
6. Trustable Remote Verication of Web Services
7. Model Based Behavior Attestation

MAC mechanisms on Mobile Platform

In our use case we have the health-care organization as the owner of the platforms in general but some operational rights are still with manufacturer and the operator for reliability and assurance of trusted state for all stakeholders. So if any stakeholder has rights on certain resources then that is equivalent to having a degree of ownership that it controls as an operator. The high level servicing interfaces are managed with IPC mechanism of the runtime environment exposed to platform owners that use the device for personalized business models.

To secure the runtime of the platform a business model has to be regulated by the operators, where user is also an operator in some cases. Mandatory access control mechanism is used by the primary owner and operator. Normally the primary operator and owner are network operators and device manufacturers. The MAC mechanism has to be operated remotely by the network operator as the trusted party for low level and protected interfaces. These interfaces are for the regulations between the mandatory stakeholders, while other stakeholders of the platform are at platform owner’s discretion/regulation.

In this activity we analyzed existing mechanisms and selected SELinux as our MAC mechanism for the OpenMoko platform due to clean and stable support on the pristine Linux kernel, a vast user base. We also ported the mechanism to our target platform and also proposed a policy model that suits the use cases in mobile based business models.

Policy and Rights Management in Multi-stakeholder model

A very critical point to understand usage control in distributed systems, especially service oriented architectures with consumption oriented client platforms, is to regulate the usage model by figuring out the owners and stakeholder of a resource. In other words the rights to configure policy, audit or measure properties of the client platform’s runtime environment.

Therefore this activity was used to understand the nature of business models in mobile computing. There are multiple stakeholders involved in the context of a usage. An object being consumed will require assurance of a trusted state from the platform and also require the measurement and reporting of other environmental properties that are required by the business or usage model.

Linux kernel with security mechanisms supported for the mobile platform

Indeed a very dynamic task, which would need attention once and a while after every two months or so to keep updated with latest kernels suitable for our mobile platform OpenMoko. Initially we tried kernel versions 2.6.26 and 2.6.29-rc3 in parallel to check which one would work out better. The reason was that 2.6.26 had features built in like our latest kernel tuned for this project (2.6.32) but unfortunately 2.6.26 was broken due to no maintenance from the community. The functionality we wanted (IMA) was available alongside SELinux in 2.6.30 for the first time, Therefore we decided to backport the patches that we derived from 2.6.30 and applied them to 2.6.29-rc3. This was tedious as there were some differences in the VFS layer of the two kernels. Fortunately the kernel booted with success and was able to provide low level interfaces for the two security sub-systems that we are interested in.

While experimenting with other kernels at home as a hobby some of the developers were able to encourage the community to update to a stable kernel 2.6.32. This provided a clean kernel for our platform which did not need any custom patching from us.

Usage control Engine

The implementation of the UCON framework is based on Java and is developed for deployment on the Openmoko mobile platform. It serves as a prototype that realizes the key features of the UCON framework to provide a general purpose mechanism that can be used to implement usage control policies.

UCON is a general purpose framework that systematically incorporates traditional access control, trust management and digital rights management and provides fine grained control over the usage of digital objects and is designed to provide effective protection in modern digital computing environments and distributed systems.

The engine is logically divided into the following modules:

  Access Manager: responsible for managing and regulating access to objects. The module is responsible for processing the requests of subjects for exercising rights on objects and also
decides whether to grant or to deny access. The decision about access to an object is taken with the help of the policy evaluator.

  Context Manager: the context manager keeps track of all the active usage sessions on an object and is instrumental in realizing the continuity aspect of the UCON model.

  Primitive Actions Manager: the primitive actions that are specified in the usage policies. The attribute updates are performed with the help of attribute update manager.

 Policy Evaluator: the policy evaluator module retrieves and parses the UCON policies associated with the usage of an object.

 Expression Evaluator: the expressions within a UCON policy are evaluated by the expression evaluator. These expressions are instrumental in the evaluation of usage policies and the attribute updates performed during the enforcement of policies.

 Attribute Update Manager: the attribute update manager implements the attribute mutability aspect of the UCON model. The attributes are stored and updated in XML files that contain the subject and object attributes.

 Attribute Reader: the attribute reader retrieves the values of the subject, object and environment attributes. These values are needed in the evaluation of expressions during the policy evaluation and attribute update process.

Realization of Trust module for mobile platforms

Immutable roots of trust (for storage, measurement, verification, enforcement and reporting) and trusted capabilities for mobile platforms are required to leverage a TCB on any given computer platform. This task is more complex and useful for the mobile platforms. The reason is that mobile platforms have a performance limitation, while the business model also demands trust management and rights management between different stakeholders whom resources are being consumed on the platform.

To reduce complexity and ensure stable and productive results we did not develop anything from scratch but used the TPM emulator to provide the trusted capabilities. The role of roots of trust is partially being provided by the emulator.

Applied cryptography in Trusted Computing

In this activity we studied the nature of trusted computing realized with applied cryptography. PrivacyCA and CA were used to regulate usage control.

Behavior identification and association

A target policy model is analyzed thoroughly to identify a general set of behaviors associated with its distinct components (step 0-1 in diagram below). This identification helps to categorize which set of behaviors of a policy model should be trusted. These behaviors are used to determine the trustworthiness of the target platform at which the policy model is realized. This step has to be performed only once for each policy model. The results can then be re-used in all systems which need to attest the policy model.

In the behavior specification step, the system designer specifies the behavior of a policy model’s components. A formal specification of such behaviors helps to abstract the complex details of the underlying hardware and software platforms.

We note that a policy is an instance of a model and is composed of several components of the model. The set of behaviors associated with different components of a policy are collectively referred as the expected behavior of the policy. An automatic way of associating such behaviors with different components of a policy model can simplify the behavior association and its
specification. The end product of this step is a high-level behavior policy. We include one such algorithm which can automate this procedure during the specification of UCON behaviors.

New attestation technique and prototype implementation

In progress …

Leave a Reply