1. Milestone 6 contains openmoko rootfs along with all the required libraries, Flash it to your device or Copy it to the memory card.

2. Milestone 5 contains the kernel (uImage.bin), Flash it to your device or Copy it to the First (FAT partition) partition of your memory card.

3. Milestone 3 contains the Userspace libraries and binaries for selinux, copy the contents of lib to /usr/lib folder of device and contents of bin to /usr/bin of device.

4. Milestone 8 contains MTM emulator and required utilities, use the Following method to install MTM emulator on openmoko.

a. Extract tpm-binaries.tar.bz2

i. Copy *.h files to /usr/include folder of Device

ii. *.so, *.l and *.la to /usr/lib folder of Device

iii. The rest of Binaries to /usr/bin folder folder of Device

iv. Copy tpmd_dev.ko from milestone 5 to /lib/modules/<kernel_version>/kernel/drivers/char/tpm on device

b. Install the IPKs using the following command

$opkg install tpm-tools-1.2.5.1_0.1_armv4t.ipk

$opkg install trousers-0.3.4_0.1_armv4t.ipk

5. Milestone 10 contains ucon, the verifier module and the tpm’s pcr read utility, use the following method to make it operational on Mobile device

a. Copy UCON_Final.tar.bz2 and verification_jar.tar.bz2 and pcr_reader_java.zip to your home folder on device.

b. Extract them

c. To run ucon, change your directory to ucon_final and run the following command

$java -jar ucon.jar

Note:

It will execute and will take some time, it will produce two types of logs, the more detail xml log (meta/log/usage_log.xml) and the log containing hashes (/var/ucon_hashes)

d. Run the verifier, change the directory to verification and run the following command

$java -jar verifier.jar

It will execute and recalculate the hashes from the ucon_hashes file in /var/ and it will give u a final hash.

e. Now we have to compare this hash store in PCR 11 of the TPM, to see that, change your directory to pcr_reader_java and run the following command

$java -jar pcr_reader_java.jar

Read the value of PCR11 and compare it with hash produced by verifier, if they are the same means that the log isn’t tampered.

The presentation includes: version control system, the repository, file sharing problem, Lock-Modify-Unlock Solution, Drawbacks of Lock-Modify-Unlock Solution, Copy-Modify-Merge Solution, Git and its protocols, performance and Subversion-Style Workflow, Integration Manager Workflow, Dictator and Lieutenants Workflow, staging and Getting a repository, commits and naming them , heads and tags, Checking out different versions of project, Manipulating branches, Understanding History, patches and branching and much more. …

download

download

Resources
Attributes
Policy Repository
Attributes Repository
PDP
Central PEP
Distributed PEPs
Levels of usage control
System level
Application level

download

Title: Android Runtime Security Policy Enforcement Framework

Authors: Hammad Banuri1 · Masoom Alam1 · Shahryar Khan1 · Jawad Manzoor1 · Bahar Ali1 · Yasar Khan1 · Mohsin Yaseen1 · Mir Nauman
Tahir1 · 1 Tamleek Ali · Xinwen Zhang2

Abstract: Today smart phone’s malwares are deceptive enough to spoof itself as a legal mobile application. The front end service of Trojans is attractive enough to deceive mobile users. Mobile users download similar malwares without knowing their illegitimate background threat. Unlike other vendors, Android is an open source mobile operating system and hence it lacks a dedicated team to analyze the application code and
decide its trustworthiness. We propose an augmented framework for Android that monitors the dynamic behavior of application during its execution. Our proposed architecture called Security Enhanced Android Framework (seaf) validates the behavior of an application through its permissions exercising patterns. Based on the exercised permissions’ combination, the mobile user is intimated about the dangerous behavior of an application. We have implemented the proposed framework within Android software stack and ported it to device. Our initial investigation shows that our solution is practical enough to be used in the consumer market.

download

by engrshahrs

Title: Semantically Rich Application Centric Security in Android

Contents:This presentation is based on the idea given in the research paper “Semantically Rich Application Centric Security in Android”.  This presentation contains the following contents:

Smart Phones

Android Security

Saint Architecture

Features Of Saint Model

Conclusion

Download here

Download

9.         Completion of Design and Implementation of Policy writing tool.    A package containing the new policy writing tool including usage doc.

Extending Android Security for Intent Policies is a Govt funded research project approved by National Information and Communication Technologies Research and Development (Ministry of Information and Technology) Govt of Pakistan. (ICT R&D)

When it started ?

The project has been started sooner its approval for funded agency since 15 of August 2009. Its two years project which will reach its completion on 15th August 2011.

Who are working on EASIP  ?

The EASIP project is assigned to Security Engineering Research Group (SERG) having 6 developers and 3 research associates, some internees and lead by Dr. Muhammad Masoom Alam as  a Project Director.

What is aim of EASIP ?

To develop a comprehensive access control framework and a policy language for the Android platform.

To implement :

A policy enforcement framework

A policy writing tool to facilitate the policy writing for the application owners and developers.

What can be found on this page related to EASIP ?

This page includes articles on the project covering deliverables, milestones, links to useful sites , viewers comments and suggestions etc.

ABSTRACT

Android is the first comprehensive open source mobile software stack, destined towards consumer market. It consists of complete mobile operating system supported by Linux kernel, a newly built Dalvik virtual machine, and some smart mobile applications. Android systemarchitecture is composed of applications, its framework,native c/c++ libraries, Android runtime (which is further consist of Dalvik virtual machine and Android core libraries which reflects the functionality of core libraries written in java), and at last the Linux kernel use to managethe low level resources. The Android application architecture has four basic components; these are activities, services, broadcast receivers,and content providers. Every Android application may comprise of one or more such components. The purpose of this report is to discussthe application components and their life cycle in detail. Moreover, the permission model and security architecture of Android are explained separately in this report. Android system implements security at process level. Variables, such as user IDs and group IDs are use to identify the  applications, which in turn use to control access of that application. The components of one application could access the services provided by other application’s components, this inter component communication is controlled through permissions assigned in AndroidManifest.xml file. The URI based security permissions further refines the control access to any application’s component. Some security holes were found in  Android; in response Google has suggested some remedies to such security bugs. The report also incorporates a case study to elaborate the application’s component life cycle.

OBJECTIVES

This document is written as part of the research project EASIP (Extending Android Security for Intent Policies) funded by ICT R&D. It has mainly three objectives. Firstly, we present the application components and their life cycle. Secondly, we present the existing Android security mechanisms to elaborate what is going on within Android at the moment. Finally, this report will lead us to complete EASIP’s next milestone, i.e. the implementation of a rudimentary ‘Selective Permission Mechanism for Android’.

INTRODUCTION

Android is the first comprehensive open source mobile platform, equipped with operating system, a Dalvik middleware, Linux kernel and with some rich modern day handset applications. The open source licensing of Android, gives freedom to developers to develop applications without concerning the royalty and licensing cost. There is no such cost of membership, testing, and digital certification fees involved in the development of Android application. The Android SDK provides the tools and APIs necessary to begin developing applications on the Android platform using the Java programming language. Developers mostly choose the popular Eclipse Integrated Development Environments for development. The innovative Android is positioned well to confront the current challenge of mobile market place.

Features of Android

1. Android Software Development Kit:  The android SDK includes an emulator, some tools for performance profiling and debugging.
2. Dalivik Virtual Machine: It is specifically designed for Anroid platform and optimized for mobile devices, where resource constraints is an issue
   (like low memory, small size, and lower processing power). Dalvik is capable of executing programs written in Java.
3. Graphics Support: Android have support for both 2D and high performance 3D graphics where the OpenGL is used to provide support for 3D graphics.
4. SQLite:  Android use small sized SQLite as an RDMS(Relational DataBase management System)
5. Connectivity: Android is provided with modern day communication technologies. It supports Bluetooth, WiFi, UMTS, CDMA, EDGE and 3G.
6. Media Support: Android has got support for different picture formats, including JPEG, BMP, GIF, PNG etc. H.263 and H.264 are video coding techniques supported by Android. H.263 is specialized for video conferencing, H.264 is basically MPEG-4 standard, use to offer high video compression.

Android System Architecture

The Android system architecture comprise of four layers. The lowest of all is Linux kernel layer, used as an abstraction between hardware and the remaining software stack of Android. The basic reason to choose Linux 2.6 as kernel, as it is an open source and has proven driver model. It makes Android a robust operating system structure. Android rely on kernel for memory management, security model, network stack and process management. The Android current architecture relies on MSM7200A Qualcomm chipset for following features.

Libraries

The native libraries of Android are written in C/C++, used by various components of Android. They act as point of contact between higher abstract layers and lower level components. They provide implementation of services provided by android to various applications.

Android Runtime

Along with native libraries, the Android runtime is on second layer right above the Linux kernel. The Android runtime consist of Dalvik virtual machine and some core libraries (it inherit almost all features provided by the core libraries of Java programming language).

Application Framework

Application Framework is on third layer going from bottom to top. It is basically a built-in toolkit, use to provide different set of services to Android applications. All those services which utilizes by core applications are make available for the Android developers to build innovative and rich Android applications. The application architecture is designed to simplify the reuse of components; any application can publish its capabilities and any other application may then make use of those capabilities (subject to security constraints enforced by the framework) through underlying components of application framework layer.

The Activity Manager manages the lifecycle of the applications and provides a common navigation backstack of applications that are running in different processes The Package Manager maintain track of all applications that are installed in the device. The Telephony Manager support applications to access the information regarding telephony servicesContent Providers supports the sharing and accessing of data among applications; suppose the messaging service is an application that can access the data of other application contacts. time. Android supports a number of different kindsof resource files, including XML (use to store anything, other than bitmaps andRaw), Bitmap (Use to store images), and Raw files (other resources such as sound, string, etc).

ANDROID SECURITY ARCHITECTURE

Security is implemented at process level in Android. It implements security procedures through different mechanisms at different levels. This includes implementing security at application level through user and group ID’s. At component level it makes usebof permission mechanism to restrict access to specific component while at data level it implements security through per URI basis permissions. Android architecture is defined such that no application can perform an operation on any other application, its components or its data, such as, Reading and/or writing. The only way to get access to any component or data is to explicitly declare the permissions it needs for that specific additional capabilities. It is implemented on two levels; Application level security and components and  data level security.

Application Level Security

Android is a multi-process system, in which each application (and parts of the system) runs in its own process. Most security between applications and the system is enforced at the process level through standard Linux facilities, such as user and group IDs that are assigned to applications. Additional finer-grained security features are provided through a “permission” mechanism that enforces restrictions on the specific operations that a particular process can perform, and per-URI permissions for granting ad-hoc access to specific pieces of data.

Mechanism employed are:

• Security implemented by Application Signing using Certificates mechanisms
• Security enforcement using USER ID
• Security enforced on File

Components Level Security

Each application runs as a unique user identity, which lets Android limit the potential damage of programming flaws.

• Core idea of Android security enforcement – labels assignment to applications and components
• A reference monitor provides mandatory access control (MAC) enforcement of how applications access components.
• Access to each component is restricted by assigning it an access permission label; applications are assigned collections of permission labels.

When a component initiates ICC, the reference monitor looks at the permission labels assigned to its containing application and— if the target component’s access permission label is in that collection— allows ICC establishment to proceed.

To view a detailed report click here