Security Frame Work for Android

8/8/2019 Security Frame Work for Android

1/43

1. PREAMBLE

1.1 INTRODUCTION

The next generation of open operating systems won't be on desktops or mainframes but on the

small mobile devices we carry every day. The openness of these new environments will lead to new

applications and markets and will enable greater integration with existing online services. However, as

the importance of the data and services our cell phones support increases, so too do the opportunities

for vulnerability. It's essential that this next generation of platforms provides a comprehensive and

usable security infrastructure.

Android is the widely anticipated open source operating system for mobile devices by the Google

Foundation. It is an integrated stack consisting of OS, middleware, user-friendly interface and

applications. It allows the users to develop additional software and change & replace the

functionalities without limitations.

Native and third-party applications are written using same APIs as well as executed on same

runtime. Hence theres no prioritizations between the two as in other OS & therefore overcomesartificial barriers for developers from building increasingly powerful software. It has powerful APIs,

excellent documentation, thriving developer community and NO development & distribution charges.

Applications in Android provide their components to be accessible to other applications. Such

applications simply search and use appropriate service providers at Run-time rather than bind itself to

implementations during development. This allows rich culture of use and extend development in

android.

Even though this platform seems to be very familiar to use and work with, but the security

requirements of these relatively new systems and the applications they support are still under study.

Therefore security infrastructure in currently available operating systems is underdeveloped.

Android has a unique security model because of the open nature of the platform that allows

proprietary extensions and changes. This extension can interfere with the security of the system.

The Security model is System-Centric which gives applications a limited ability to govern to whom

rights to data and interfaces must be given Therefore an important step is in protection of information

of such system using different security policies and make it Application-Centric. Considering the

security requirement of these, here we augment the existing Android OS with a Framework to meet

them. The resulting new framework will now have a new security component. The main security

aspects taken care of by this new component are Confidentiality, Authentication, Integrity and

Authorization.

To provide an overall view, this project is based on the emerging new Technology, Android and the

main aim is to provide secured data transfer between two or more applications and make it

application-centric. This mainly involves the study of a new operating system technology, security

networking, mobile computing and the creation of Java application on the Android platform.

1.2 PROBLEM DEFINITION

The proposed problem is to design a secured Android content sharing framework which

provides maximum security for the data being communicated via the android platform achieving

1 | P a g e


2/43

security elements like confidentiality, authentication and authorization.

1.2.1 Purpose

To develop content sharing secured application framework for android to transfer data during

mobile communication.

Mobile data transfer has no security during actual communication. The service provider is justinvolved in the direction of data from source to destination. Data is transmitted in the form of clear text

even in Bluetooth transmission.

Instead of using standard application of android we develop a secured framework that

contains our application.

1.3 OBJECTIVES OF THE PROJECT

The basic purpose is to provide a secured form of data transmission on the Android platform.

To learn the current Android application framework and its components and functionalities.

Create our own application using an IDE like NetBeans.

To include this application on the existing Android application layer.

To create and run data on the Android emulators using the Android SDK.

To provide security for the same data being transmitted through our application by

augmenting the existing framework with a security component.

To be able to encrypt and decrypt the data at the sender and receiver ends respectively.

To ensure protection of data being transmitted on the Android platform from any unauthorized

user.

1.4 SCOPE OF THE PROJECT

Present scope:

The current framework lacks security during the actual transmission of the data between two

systems.

Our application will provide a maximum possible security during such transmissions.

Incorporation ofsuch an application into the existing system will help the users to send any

kind of private and confidential information without any threats.

This data being sent is encrypted and hence only an authorized user can crack the actual

information, on providing appropriate keys.

Application use granted only to the authorized user through password verification, to ensure

the application is being used only by the intended user.

Applications can be developed on mobile devices we carry everyday and extended to other

devices like notebooks and palmtops unlike other operating systems which lack such extensions.

2 | P a g e


3/43

2. SYSTEM STUDY AND REQUIRMENT ANALYSIS

2.1 Existing system:

The security model of android system is System-centric. Hence the applications have limited

ability thereafter to govern to whom rights to data and interfaces are given and how they are

exercised.

Since the Android OS is based on Linux kernel it provides a good amount of security but, this

security is only system-centric. Security is provided for standalone applications but not to those

applications between which the actual data transfer is taking place.

Service providers provide no reliable security for data being shared among applications on

different systems. Data like messages and call lists form an important part of data exchanges in

business and economic environments but there exists no provisions for confidentiality.

Advantages:

1) Android system protects the system from malicious software.

2) Allows a rich culture of use and extend development that has led to an explosion of innovative

applications.

Disadvantages:

1) Limited infrastructure for applications to protect themselves.

2) Three essential application policies are not available to the applications in the Android

Security framework.

a) Permission assignment policy-Applications have limited ability to control to which permissions for

accessing their interfaces are granted.

Ex- White or black list applications.

b) Interface exposure policy - Android provides only rudimentary facilities for applications to control

how their interfaces are used by other applications.

c) Interface use policy- Applications have limited means of selecting at runtime which applications

interfaces they use.

2.2 Proposed System

We introduce a framework that extends the existing android security architecture and adds a

new security component. This component takes care of the key security requirements necessary for

the applications that share private data.

This transforms the current android model to application-centric where applications have

enough ability to govern to whom rights to data and interfaces are given.

2.2.1 Advantages of the proposed system:

3 | P a g e


4/43

1) A sender can send data only to a trusted receiver.

2) Key security requirements like confidentiality and privacy provided for applications that need

security from threats.

3) A sender can restrict the use of the service only to trusted networks under safe conditions.

4) Improved versions of algorithm or software to prevent key or password leaks.

5) Three essential application policies are made available to the applications in the Android Securityframework.

6) Preservation of location privacy.

2.3 Feasibility Study

2.3.1Economic Feasibility

No necessity of the actual Android phones to show communication just a computer with an

android SDK, an open source product that comes with an inbuilt emulator is used. Since it is freely

available its economically feasible.

2.3.2 Behavioral Feasibility

The application is developed in order to provide data security for transmission of call lists,

messages and images for the end users. A user can easily work on emulators just like he uses his

mobile keypad.

Both the sender and receiver are assured of secured communication because- Key aspects

like Data privacy and confidentiality provided for both the sender and the receiver. Only intended

users can have access to applications.

2.3.3Technical Feasibility

To deploy the application the technical aspects needed are as follows.

Software: NetBeans 6.5, Android SDK 2.0

Interface: XML

2.4 REQUIRMENT SPECIFICATION

2.4.1 Hardware specification

Pentium class machine

System Memory ( RAM):1 GB

Internal Database.

Hard Disk(Free space):500MB

Screen: 1024x768, "16-bit High Color" screen*/

The Android SDK requires disk storage for all of the components that you choose to install. The

table below provides a rough idea of the disk-space requirements to expect, based on the

components that you plan to use.

Component type Approximate size Comments

4 | P a g e


5/43

SDK Tools 50 MB Required.

Android platform (each) 150 MB At least one platform is required.

SDK Add-on (each) 100 MB Optional.

USB Driver for Windows 10 MB Optional. For Windows only.

Samples (per platform) 10M Optional.

Offline documentation 250 MB Optional.

The Android SDK includes a comprehensive set of development tools. These include a

debugger, libraries, a handset emulator, documentation, sample code, and tutorials. Currently

supported development platforms include x86-architecture computers running Linux (any modern

desktop Linux distribution), Mac OS X 10.4.8 or later, Windows XP or Vista. Requirements also

include Java Development Kit, Apache Ant, and Python 2.2 or later. The officially supported integrated

development environment (IDE) is Eclipse (3.2 or later) using the Android Development Tools (ADT)

Plug-in, though developers may use any text editor to edit Java and XML files then use command linetools to create, build and debug Android applications as well as control attached Android devices (e.g.,

triggering a reboot, installing software package(s) remotely).

2.4.2 Software specification

The sections below describe the system and software requirements for developing Android

applications using the Android SDK.

1) Supported Operating Systems:

Windows XP (32-bit) or Vista (32- or 64-bit).

Other supporting OS are: Mac OS X 10.5.8 or later (x86 only), Linux (tested on Linux Ubuntu

Hardy Heron).

2) Supported Development Environments:

NetBeans

.NET Compact Framework Used primarily for applications on Pocket PC/Windows Mobile devices,

although it is now being extended to Android devices

Eclipse IDE

Eclipse Classic (versions 3.5.1 and higher)

3) Development Tools:

The Android SDK includes a variety of custom tools that help develop mobile applications on

the Android platform. The most important of these are the Android Emulator and the Android

5 | P a g e


6/43

Development Tools, but the SDK also includes a variety of other tools for debugging, packaging, and

installing our applications on the emulator.

Android Emulator:

A virtual mobile device that runs on computer use the emulator to design, debug, and test r

applications in an actual Android run-time environment.

Android Development Tools:

It provides a New Project Wizard, which helps quickly create and set up all of the basic files will need

for a new Android application. It automates and simplifies the process of building our Android

application. It provides an Android code editor that helps write valid XML for our Android manifest and

resource files.

Dalvik Debug Monitor Service (ddms) -Integrated with Dalvik, the Android platform's custom VM, this

tool lets manage processes on an emulator or device and assists in debugging. can use it to kill

processes, select a specific process to debug, generate trace data, view heap and thread information,

take screenshots of the emulator or device, and more.

Android Debug Bridge (adb) -The adb tool lets install application's .apk files on an emulator or device

and access the emulator or device from a command line can also use it to link a standard debugger to

application code running on an Android emulator or device.

Android Asset Packaging Tool (aapt) -The aapt tool lets create .apk files containing the binaries and

resources of Android applications.

Android Interface Description Language (aidl) -Aidl Lets generate code for an interprocess interface,

such as what a service might use.

Sqlite3 -Included as a convenience, this tool lets access the SQLite data files created and used by

Android applications. Trace view -This tool produces graphical analysis views of trace log data that

can generate from r Android application.

mksdcard -Helps create a disk image that can use with the emulator, to simulate the presence of an

external storage card (such as an SD card).

dx -The dx tool rewrites .class bytecode into Android bytecode (stored in .dex files.)

activityCreator - A script that generates Ant build files that can use to compile our Android applications.

If are developing on Eclipse with the ADT plugin, won't need to use this script.

2.4.3 Functional requirements and Non functional Requirements

Functional Requirements:

6 | P a g e


7/43

Support for the Android SDK which provides the emulator.

The Android SDK includes a mobile device emulator -- a virtual mobile device that runs on your

computer. The emulator lets you prototype, develop, and test Android applications without using a

physical device.

The Android emulator all of the hardware and software features of a typical mobile device, except that

it can not receive or place actual phone calls. It provides a variety of navigation and control keys,

which you can "press" using your mouse or keyboard to generate events for your application. It also

provides a screen in which your application is displayed, together with any other Android applications

running.

The emulator also includes a variety of debug capabilities, such as a console from which you can log

kernel output, simulate application interrupts (such as arriving SMS messages or phone calls), and

simulate latency effects and dropouts on the data channel.

Encryption of the data to be communicated.

Decryption of the data to be communicated.

-Secured message transfer is deployed on android phone.

-Data is encrypted and decrypted through the secured messaging component of the Android phone.

Data is sent and received to the message box of the authenticated user.

Creation of the user interface.

Basic unit of an Android application is an Activity. An Activity displays the user interface of your

application, which may contain widgets like buttons, labels, text boxes, etc. Typically, you define your

UI using an XML file.

An Activity contains Views and ViewGroups. A View is a widget that has an appearance on

screen. Examples of widgets are buttons, labels, text boxes, etc. A View derives from the base

class android.view.View.

Android supports the following ViewGroups:

LinearLayout

AbsoluteLayout

TableLayout

RelativeLayout

FrameLayout

ScrollView

7 | P a g e


8/43

Provision of the authentication facility in the form of security keys or private keys so as to

check whether the data can be decrypted and only by the intended receiver.

Interface provided by the emulator:

Non-functional requirements:

Performance Requirements: Algorithm used will provide space and time efficiency. That is, the

memory required and time taken for the encryption and decryption is very less.

Safety Requirements: Since the Android is based on a Linux Kernel, it has an inherent feature

of providing security between each application on the mobile. Hence even if any error occurs in the

new application the other existing applications are not affected.

Security Requirements: The application provides security for the communication of data which

requires proper authentication. Here user identity authentication is required. Android mobile

phone platform is going to be more secure than Apples iPhone or any other device in the long

run. There are several solutions nowadays to protect Google phone from various attacks. One

of them is security vendor McAfee, a member of Linux Mobile (LiMo) Foundation. This

foundation joins particular companies to develop an open mobile-device software platform.

Many of the companies listed in the LiMo Foundation have also become members of the

Open Handset Alliance (OHA).

Software quality attributes:- Adaptability, interoperability, portability, robust and testability.

Extended functionality - Mobile applications can provide application functionality or utility that

is not natively available on the Android smartphone or is significantly better than what currently exists.

Remote access - Mobile applications can extend business software functionality for field

employees and give their employees the opportunity to access information easily from anywhere

where they have access to the Internet.

Brand visibility -Mobile Android applications offer deep aligned and integrated brand

experiences any time they are used.

Monetization : Mobile Android applications allows developers and publishers to monetize the

apps by serving text, image and rich media ads on CMP basis

Supportability (Ease of installation): This SDK is very easy to install and its open source.

2.4.4 Use case diagram

8 | P a g e


9/43

Fig 2.4.4 Use case diagram

2.5 TEST PLAN

Test case id Test case module

name

Input Output

1 Mobile1

(Create Message)

Data(sms,contact

list)

Encrypted data

Round 1(cipher text

1)

Access allowed

Round 2(cipher text

2)

Access allowed

Round 3(cipher text

3)

Access allowed

2 Mobile 2

(Open inbox)

Round 3(clear text

3)

Access allowed

(denied)

Round 2(clear text

2)

Access allowed

(denied)

Round 1(clear text

1)

Access allowed

(denied)

Encrypted data Decrypted

data(SMS ,Contact

list)

9 | P a g e


10/43

Use case

Use Case ID 1

Primary Actor Sender, Receiver (Users)

Brief Description The communication of encryption data b/w sender and data.

Trigger The user installs the system application

Preconditions The network is active

Flow of Events # Actor System

1 The Sender creates data.

2 Created data wil be encrypted

3 Encrypted message is transmitted.

4 The authenticated userreceives the message

5 Encrypted message is decrypted.

6The message is read by

the Receiver.

Post-conditions Users are transmitted the data in the secured way.

Alternative flows and

exceptions

6.a - If the authentication fails while receiving the data ,the received

data will not be decrypted and cannot be read.

fig 2.5.2 use case

3. SYSTEM DESIGN

3.1 Architectural Design

3.1.1 Architectural Design approach

Single-Tier Architecture:

10 | P a g e


11/43

Fig 3.1.1 Single Tier Architecture

Here user interface of the application, the middle ware and the data access are all contained

in one whole architecture.

In this application architecture everything resides in a single program framework.

Presentation layer provides with views which act as user interface.

Business logic comprises of business rules as well as services that act as input to the

presentation layer.

Service layer contains databases which are required by the other layers.

Modified Application System Architecture

Fig3.1.2Modified Application System Architecture

Application Framework enables reuse and replacement of components.

Application Layer is incorporated with Secured Messaging component.

Application Framework is incorporated with Security Manager component.

11 | P a g e


12/43

Both together take care of security issues related to data transfer ( messages, contact list).

Application Software Architecture

Fig 3.1.3 application software architecture

The architecture design approach is single tier. Single tier architecture is the simplest

configuration suitable for environment where cost and simplicity are the driving forces.

A single machine runs the application components. In single tier architecture end user directly

requests for secured data sharing.

There are no application servers involved in the process. This architecture is based on

messaging and android APIs. This set up offers advantage of being less complex and less

costly to implement.

However looks and feel can be customized.

The important aspect of architecture is determining what technology will be used for

communication of data like messages and call list and how the responses are handled.

3.2 DETAILED DESIGN

3.2.1 Data Flow Diagrams

3.2.1.1 Data flow design

12 | P a g e


13/43

Authenti

Fig 3.2.1 Data flow design

Initially sender is authenticated.

Only authenticated user is permitted to create and send the message.

Original message is encrypted and sent.

This is decrypted and saved in the receiver side message box.

Again only the authenticated user is permitted to read the message.

Only the authenticated user can save the message in the message box if required.

3.2.1.2 COMPLETE SEQUENCE DIAGRAM

13 | P a g e


14/43

: A u t h e nM a n a g

Fig., 3.2.2 complete sequence dig,.

The sequence of flow is as follows:

Authentication manager is responsible for permitting the creation of message by the

authorized user.

Once the message is framed the underlying encryption logic encrypts the data and is now

ready for data transfer.

Received data is in its encrypted form and only the authenticated user is allowed to read its

decrypted form.

3.2.1.3 Deployment Diagram for SMS message

Fig 3.2.3 Deployment diagram1

Secured message transfer is deployed on android phone.

14 | P a g e


15/43

Data is encrypted and decrypted through the secured messaging component of the Android

phone.

Data is sent from and received to the message box of the authenticated user.

3.2.1.4 Deployment Diagram for transfer of contact list

Future enhancement:

The transfer of contact list is possible using the similar mechanism as used for secured messaging.

3.2.1.5 Deployment Diagram for transfer of videos

Future Enhancement

Secured transmission of audio.........

3.2.1.6 Sequence Diagram for Authentication

15 | P a g e


16/43

Fig.,3.2.4 Sequence Diagram

This is the sequence diagram for the initial phase of the system.

Initially user authentication is performed by entering login and password.

If it is verified as a valid user then there is an access grant otherwise there is denial of access.

3.2.1.7 Sequence Diagrams for Application Access

16 | P a g e


17/43

LDi

Fig., 3.2.5 Sequence Diagram

3.2.1.8 Main Sequence Diagram

: A u t h e

M a n aFig., 3.2.6 Main sequence dig.,

Sequence diagram 1.

17 | P a g e


18/43

User authentication prevents unauthorized user from having access to the system services.

Sequence diagram 2.

Authentication manager controls access to android applications from malicious users

3.2.2 Class Diagram

A n d r o

Fig., 3.2.7 Class Diagram

Android phones can exchange messages in a secure way through the secured messaging

component.

This component performs authentication, encryption, and decryption, sending and receiving of

the message.

This component can be further enhanced for any other content sharing.

3.2.2.1 Elaborated Class Diagram

18 | P a g e


19/43

Android Phone

Fig., 3.2.8 elaborated class dig.,

Android phone provides user authentication and secured data transfer at both sender andreceiver sides.

Message from the sender message box is encrypted and sent to the authenticated user

where it is decrypted and saved.

3.3 USER INTERFACE DESIGN

3.3.1 USE CASE DIAGRAM

Fig., 3.3.1 Use case diagram.

Authenticated sender is permitted to create and send data by the system.

Data is encrypted and sent.

Receiver receives the encrypted data which is decrypted.

19 | P a g e


20/43

Finally system authenticates the receiver and saves the message.

3.3.2 Activity Diagram for Sending Data

Fig., 3.3.2 Activity dig 1.,

3.3.3 Activity Diagram for Receiving Data

Fig., 3.3.3 Activity dig 2

Activity diagram SEND:

Setting and controlling message sending permissions.

Activity diagram RECEIVE:

Setting and controlling message receiving permissions.

20 | P a g e


21/43

3.3.4 Main Activity Diagram

Fig., 3.3.4 Main Activity Dig

Login verification to provide security to intended users.

Creation of data messages to be transferred.

Encryption using standard algorithm.

Sending and receiving by controlling and setting permissions.

Message received at intended destination.

Authentication done again at receiving end to ensure the user is an intended user itself. On

authentication decryption of the message else unauthorized user ends up in failure for

cracking the original message.

21 | P a g e


22/43

3.3.5 State Diagram

Secured content

Fig., 3.3.5 State dig

The first event that changes the initial state is the user interaction.

On successive success events the user is permitted to compose, encrypt, send and decrypt

the data & hence achieve a secured content sharing communication.

On failure the user ends up in an indefinite idle waiting state.

4. IMPLEMENTATION

4.1 Introduction

22 | P a g e


23/43

The newly designed framework which contains a security component called Security Manager

provides key security aspects like confidentiality, authorization and authentication to the application

developed by our project named Secured Messaging.

This involves six main components:

1) Sender side Authentication.

2) Encryption of the composed message.

3) Sending_SMS

4) Receiving_SMS

5) Decryption of the composed message.

6) Receiver side Authentication.

4.2Module operational Specification

4.2.1 Sender side Authentication.

This module allows access to application Secured Messaging only to authorized users through

password confirmation.

if (password == assigned by developer){

Allow user to send SMS

}

else {

Display error message;

}

4.2.2 Encryption of the composed message.

Symmetric Key Cryptography

Identical keys used to encrypt/decrypt messages

Can be implemented as block ciphers or stream ciphers

Strengths:

Speed

Much less computationally intensive than public-key crypto

Easy to implement in hardware as well as software

Weaknesses:

23 | P a g e


24/43

Key Management

n users require n(n-1)/2 keys for all to communicate

secure key distribution is a challenge

Cannot be used (directly) for authentication or non-repudiation.

AES The Advanced Encryption Standard

Rijndael algorithm invented by Joan Daemen and Vincent Rijmen and selected as AES

winner by NIST in 2001

AES uses fixed block size of 128-bits and key sizes of 128, 192 or 256 bits (though Rijndael

specification allows for variable block and key sizes)

Most of the calculations in AES are performed within a finite field

There are a finite number of elements within the field and all operations on those elements

result in an element also contained in the field.

AES Operations

AES operates on a 44 matrix referred to as the state

16 bytes == 128 bits == block size

All operations in a round of AES are invertible

AddRoundKey each byte of the round key is combined with the corresponding byte in the

state using XOR

SubBytes each byte in the state is replaced with a different byte according to the S-Boxlookup table

ShiftRows each row in the state table is shifted by a varying number of bytes

MixColumns each column in the state table is multiplied with a fixed polynomial.

AES Operation AddRoundKey

Each byte of the round key is XORed with the corresponding byte in the state table

Inverse operation is identical since XOR a second time returns the original values.

AES Operation SubBytes

Each byte of the state table is substituted with the value in the S-Box whose index is the value

of the state table byte

Provides non-linearity (algorithm not equal to the sum of its parts)

Inverse operation is performed using the inverted S-Box.

AES Operation ShiftRows

24 | P a g e


25/43

Each row in the state table is shifted left by the number of bytes represented by the row

number

Inverse operation simply shifts each row to the right by the number of bytes as the row

number

AES Operation MixColumns

MixColumns is performed by multiplying each column (within the Galois finite field) by the

following matrix.

The inverse operation is performed by multiplying each column by the following inverse

matrix.

AES Pulling It All Together

The AES Cipher operates using a varying number of rounds, based on the size of the cipher key.

A round of AES consists of the four operations performed in succession: AddRoundKey,

SubBytes, ShiftRows, and MixColumns (MixColumns is omitted in the final round)

128-bit key rounds, 192-bit key 12 rounds, 256-bit key 14 rounds

The AES cipher key is expanded according to the Rijndael key schedule and a different part

of the expanded key is used for each round of AES

The expanded key will be of length (block size * num rounds+1)

128-bit cipher key expands to 176-byte key 192-bit cipher key expands to 208-byte key

256-bit cipher key expands to 240-byte key

AES Key Expansion Operations

AES key expansion consists of several primitive operations:

1. Rotate takes a 4-byte word and rotates everything one byte to the left, e.g. rotate([1,2,3,4])

[2, 3, 4, 1]2. SubBytes each byte of a word is substituted with the value in the S-Box whose index is the

value of the original byte

3. Rcon the first byte of a word is XORed with the round constant. Each value of the Rcon

table is a member of the Rinjdael finite field.

AES Key Expansion Algorithm (256-bit)

Pseudo-code for AES Key Expansion:

25 | P a g e
http://en.wikipedia.org/wiki/Rijndael_Galois_fieldhttp://en.wikipedia.org/wiki/Rijndael_Galois_field


26/43

1. expandedKey[0:32] cipherKey[0:32] # copy first 32 bytes of cipher key to expanded key

2. i 1 # Rcon iterator

3. temp = byte[4] # 4-byte container for temp storage

4. while size(expandedKey) < 240

temp last 4 bytes ofexpandedKey

5. # every 32 bytes apply core schedule to temp

if size(expandedKey)%32 == 0

temp = keyScheduleCore(temp, i)

i i + 1

# since 256-bit key -> add an extra sbox transformation to each new byte

forj in range(4):

temp[j] = sbox[temp[j]]

# XOR temp with the 4-byte block 32 bytes before the end of the current expanded key.

# These 4 bytes become the next bytes in the expanded key

expandedKey.append( temp XOR expandedKey[size(expandedKey)-

32:size(expandedKey)-28]

AES Encrypting a Single Block

state block of plaintext # 16 bytes of plaintext are copied into the state

expandedKey = expandKey(cipherKey) # create 240-bytes of key material to be used as round keys

roundNum 0 # counter for which round number we are in

roundKey createRoundKey(expandedKey, roundNum)

addRoundKey(state, roundKey) # each byte of state is XORed with the present roundKey

while roundNum < 14 # 14 rounds in AES-256

roundKey createRoundKey(expandedKey, roundNum)

# round of AES consists of 1. subBytes, 2. shiftRows, 3. mixColumns, and 4. addRoundKey

aesRound(state, roundKey)

roundNum roundNum + 1

# for the last round leave out the mixColumns operation

roundKey = createRoundKey(expandedKey, roundNum)

subBytes(state)

shiftRows(state)

addRoundKey(state)

return state as block of ciphertext

26 | P a g e


27/43

4.2.3 Sending_SMS

/*This module allows the encrypted message to be sent to the receiver*/

private void sendSMS(String phoneNumber, String message)

{

PendingIntent pi = PendingIntent.getActivity(this, 0, new Intent(this, SMS.class), 0);

sms.sendTextMessage(phoneNumber, null, encrypted message, pi, null);

}

4.2.4 Receiving_SMS

Decryption of the composed message.

/*This module allows the message to be decrypted at the receiver side*/

public static String decrypt(String seed, String encrypted) throws Exception {

byte[] rawKey = getRawKey(seed.getBytes());

byte[] enc = toByte(encrypted);

byte[] result = decrypt(rawKey, enc);

return new String(result);

}

SMS Messaging in Android

Sending SMS Messages

Android uses a permission-based policy where all the permissions needed by an application need to

be specified in the AndroidManifest.xml file. By doing so, when the application is installed it will be

clear to the user what specific access permissions are required by the application. For example, as

sending SMS messages will potentially incur additional cost on the user's end, indicating the SMSpermissions in the AndroidManifest.xml file will let the user decide whether to allow the application to

install or not.

In the AndroidManifest.xml file, add the two permissions - SEND_SMS and RECEIVE_SMS:

In the main.xml file located in the res/layout folder, add the following code so that the user can enter a

phone number as well as a message to send.

Next, in the SMS activity, we wire up the Button view so that when the user clicks on it, we will checkto see that the phone number of the recipient and the message is entered before we send the

27 | P a g e


28/43

message using the sendSMS() function, which is as defined above.

To send an SMS message, you use the SmsManager class. Unlike other classes, you do not directly

instantiate this class; instead you will call the getDefault() static method to obtain an SmsManager

object. The sendTextMessage() method sends the SMS message with a PendingIntent. The

PendingIntent object is used to identify a target to invoke at a later time. For example, after sending

the message, you can use a PendingIntent object to display another activity. In this case, the

PendingIntent object (pi) is simply pointing to the same activity (SMS.java), so when the SMS is sent,

nothing will happen.

If you need to monitor the status of the SMS message sending process, you can actually use

two PendingIntent objects together with two BroadcastReceiver objects.

The above code uses a PendingIntent object (sentPI) to monitor the sending process. When

an SMS message is sent, the first BroadcastReceiver's onReceive event will fire. This is where you

check the status of the sending process. The second PendingIntent object (deliveredPI) monitors the

delivery process. The second BroadcastReceiver's onReceive event will fire when an SMS is

successfully delivered.

You can now test the application. To send an SMS message from one emulator instance to

another, simply launch another instance of the Android emulator by going to the Tools folder of the

SDK and running Emulator.exe.

Simply use the target emulator's port number (shown in the top left corner of the window) as its phone

number to send the SMS. When an SMS is sent successfully, it will display a "SMS sent" message.

When it is successfully delivered, it will display a "SMS delivered" message. Note that for testing using

the emulator, when an SMS is successfully delivered, the "SMS delivered" message does not appear;

this only works for real devices.

When the message is received by the recipient emulator, the message first appeared in the

notification bar (top of the screen). Dragging down the notification bar reveals the message received.

To view the entire message, click on the message. This will be the encrypted message. To view the

decrypted message user needs to enter through our application and authenticate.

Receiving SMS Messages

Besides programmatically sending SMS messages, you can also intercept incoming SMS

messages using a BroadcastReceiver object.

To see how to receive SMS messages from within your Android application, in the

AndroidManifest.xml file add the element so that incoming SMS messages can be

intercepted by the SmsReceiver class.

28 | P a g e


29/43

When SMS messages are received, the onCreate() method will be invoked. The SMS

message is contained and attached to the Intent object (intent - the second parameter in the

onReceive() method) via a Bundle object. The messages are stored in an Object array in the PDU

format. To extract each message, use the static createFromPdu() method from the SmsMessage

class. The SMS message is then displayed using the Toast class.

To test the application select run. Deploy the application to each Android emulator.

Following figure shows that when you send an SMS message to another emulator instance (port

number 5556), the message is received by the target emulator and displayed via the Toast class.

Sending and receiving SMS messages using the Android emulators

29 | P a g e


30/43

5. TESTING

5.1 Overview

5.1.1 Authentication at the sender side:

Only authorized users are allowed to access the application by entering the password .Once theauthorization is granted the user is permitted to create the message which is sent in its encrypted

form.

5.1.2 Authentication at the receiver side:

The message received at the receiver side will be in its encrypted form. Once the receiver is

granted access to the application, the message is decrypted and and saved at the receiver side.

5.2 Test plan

5.2.1 Features to be tested

1. Application access is allowed/denied at sender side.

2. Application access is allowed/denied at receiver side.

5.3 Test cases

5.3.1 Case-1

Sno. Sender side

Authentication

MessageBox1 OnSend Receiver side

Authentication

MessageBox2

1. Success Create

message

Encrypt Success Decrypt and

Receive

2. Failure -- -- -- --

3. Success Create

message

encrypt Failure --

30 | P a g e


31/43

6. RESULTS

Snap shots

The above figure shows the selection and the start of AVD device to run emulator devices.

Authentication provided on both sender and receiver sides.

Application access provided only on successful password confirmation.

31 | P a g e


32/43

Confirmation that both users are the intended users.

The sender now allowed to compose and send a message

32 | P a g e


33/43

The receiver receives the encrypted message and the sender notified about the delivery.

The original message is received by the authenticated receiver.

33 | P a g e


34/43

Unauthorized user can only have access to encrypted message.

7. CONCLUSION AND FUTURE SCOPE OF PROJECT

34 | P a g e


35/43

7.1 CONCLUSION

This project implements a framework that contains a security component called Security

Manager providing required security elements like confidentiality, authorization and authentication for

data composed and sent using Secured Messaging application. Thus transforming a system from

system-centric to application-centric.

Following are the objectives met by the project:

Learnt the current Android application framework and its components and functionalities.

Created our own application using an IDE like NetBeans.

We included this application on the existing Android application layer.

Created and executed the data on Android emulators using the Android SDK.

Provided security for the same data being transmitted through our application by augmenting the

existing framework with a security component.

Encrypted and decrypted the data at both sender and receiver ends respectively.

Ensured the protection of data being transmitted on the Android platform from any unauthorized

user.

7.2 FUTURE SCOPE

No application can leave the clients totally contented, theres always a room for improvement.

Secured transmission of some other forms of data like music files, videos, etc.

Cross platform secured application interaction.

Secured application interaction across different systems using IPC mechanisms like Socket

programming.

Future Scope may also include communication between two different mobile phones deployed

with different OS, since the application we create is platform independent.

35 | P a g e


36/43

8. RERERENCES

Papers

1) Machigar Ongtang, Stephen McLaughlin, William Enck, and Patrick McDaniel.

Semantically Rich Application-Centric Security in Android. Proceedings of the 25th

Annual Computer Security Applications Conference (ACSAC), December 2009.

Honolulu, HI.

Books:

1) Android Application Development Reto Meier

Websites:

1) http://www.androiddevelopers.com/

2) http://www.code.google.com/android/

APPENDIX A: Tools Description

Programming Language: Java

The android applications are written using java programming language. The language derives much

of its syntax from C and C++ but has a simplerobject model and fewer low-level facilities. Java

applications are typically compiled to bytecode(class file) that can run on anyJava Virtual Machine

(JVM) regardless ofcomputer architecture. Java is general-purpose, concurrent, class-based, and

object-oriented, and is specifically designed to have as few implementation dependencies as possible.

It is intended to let application developers "write once, run anywhere". Java is considered by many as

one of the most influential programming languages of the 20th century, and is widely used fromapplication software to web applications

One characteristic of Java is portability, which means that computer programs written in the

Java language must run similarly on any supported hardware/operating-system platform. This is

achieved by compiling the Java language code to an intermediate representation called Java

bytecode, instead of directly to platform-specific machine code. Java bytecode instructions are

analogous to machine code, but are intended to be interpreted by a virtual machine (VM) written

specifically for the host hardware. End-users commonly use a Java Runtime Environment (JRE)

installed on their own machine for standalone Java applications, or in a Web browser for Java applets.

36 | P a g e
http://code.google.com/android/http://en.wikipedia.org/wiki/Syntax_(programming_languages)http://en.wikipedia.org/wiki/C_(programming_language)http://en.wikipedia.org/wiki/C_(programming_language)http://en.wikipedia.org/wiki/C%2B%2Bhttp://en.wikipedia.org/wiki/C%2B%2Bhttp://en.wikipedia.org/wiki/C%2B%2Bhttp://en.wikipedia.org/wiki/Object_modelhttp://en.wikipedia.org/wiki/Object_modelhttp://en.wikipedia.org/wiki/Object_modelhttp://en.wikipedia.org/wiki/Low-level_programming_languagehttp://en.wikipedia.org/wiki/Low-level_programming_languagehttp://en.wikipedia.org/wiki/Compilerhttp://en.wikipedia.org/wiki/Java_bytecodehttp://en.wikipedia.org/wiki/Java_bytecodehttp://en.wikipedia.org/wiki/Class_(file_format)http://en.wikipedia.org/wiki/Java_Virtual_Machinehttp://en.wikipedia.org/wiki/Java_Virtual_Machinehttp://en.wikipedia.org/wiki/Computer_architecturehttp://en.wikipedia.org/wiki/Computer_architecturehttp://en.wikipedia.org/wiki/Java_bytecodehttp://en.wikipedia.org/wiki/Java_bytecodehttp://en.wikipedia.org/wiki/Machine_codehttp://en.wikipedia.org/wiki/Interpreter_(computing)http://en.wikipedia.org/wiki/Virtual_machinehttp://en.wikipedia.org/wiki/End-userhttp://en.wikipedia.org/wiki/End-userhttp://en.wikipedia.org/wiki/Java_Virtual_Machinehttp://en.wikipedia.org/wiki/Applethttp://en.wikipedia.org/wiki/Applethttp://code.google.com/android/http://en.wikipedia.org/wiki/Syntax_(programming_languages)http://en.wikipedia.org/wiki/C_(programming_language)http://en.wikipedia.org/wiki/C%2B%2Bhttp://en.wikipedia.org/wiki/Object_modelhttp://en.wikipedia.org/wiki/Low-level_programming_languagehttp://en.wikipedia.org/wiki/Compilerhttp://en.wikipedia.org/wiki/Java_bytecodehttp://en.wikipedia.org/wiki/Class_(file_format)http://en.wikipedia.org/wiki/Java_Virtual_Machinehttp://en.wikipedia.org/wiki/Computer_architecturehttp://en.wikipedia.org/wiki/Java_bytecodehttp://en.wikipedia.org/wiki/Java_bytecodehttp://en.wikipedia.org/wiki/Machine_codehttp://en.wikipedia.org/wiki/Interpreter_(computing)http://en.wikipedia.org/wiki/Virtual_machinehttp://en.wikipedia.org/wiki/End-userhttp://en.wikipedia.org/wiki/Java_Virtual_Machinehttp://en.wikipedia.org/wiki/Applet


37/43

Standardized libraries provide a generic way to access host-specific features such as graphics,

threading and networking.

A major benefit of using bytecode is porting. However, the overhead of interpretation means that

interpreted programs almost always run more slowly than programs compiled to native executables

would. Just-in-Time compilers were introduced from an early stage that compile bytecodes to machine

code during runtime. Over the years, this JVM built-in feature has been optimized to a point where the

JVM's performance competes with natively compiled C code.

Development Tools

The Android SDK includes a variety of custom tools that help develop mobile applications on the

Android platform. The most important of these are the Android Emulator and the Android Development

Tools , but the SDK also includes a variety of other tools for debugging, packaging, and installing our

applications on the emulator.

Android Emulator

A virtual mobile device that runs on computer use the emulator to design, debug, and test r

applications in an actual Android run-time environment.

Android Development Tools

It provides a New Project Wizard, which helps quickly create and set up all of the basic filesll need for

a new Android application. It automates and simplifies the process of building our Android application.

It provides an Android code editor that helps write valid XML for our Android manifest and resource

files.

Dalvik Debug Monitor Service (ddms) -Integrated with Dalvik, the Android platform's custom

VM, this tool lets manage processes on an emulator or device and assists in debugging. can use it to

kill processes, select a specific process to debug, generate trace data, view heap and thread

information, take screenshots of the emulator or device, and more.

Android Debug Bridge (adb) -The adb tool lets install application's .apk files on an emulator or

device and access the emulator or device from a command line. can also use it to link a standard

debugger to application code running on an Android emulator or device.

Android Asset Packaging Tool (aapt) -The aapt tool lets create .apk files containing the

binaries and resources of Android applications.

37 | P a g e
http://en.wikipedia.org/wiki/Thread_(computer_science)http://en.wikipedia.org/wiki/Computer_networkhttp://en.wikipedia.org/wiki/Computer_networkhttp://en.wikipedia.org/wiki/Thread_(computer_science)http://en.wikipedia.org/wiki/Computer_network


38/43

Android Interface Description Language (aidl) -Aidl Lets generate code for an interprocess

interface, such as what a service might use.

sqlite3 -Included as a convenience, this tool lets access the SQLite data files created and

used by Android applications.

Trace view -This tool produces graphical analysis views of trace log data that can generate from r

Android application.

mksdcard -Helps create a disk image that can use with the emulator, to simulate the presence of

an external storage card (such as an SD card).

dx -The dx tool rewrites .class bytecode into Android bytecode (stored in .dex files.)

activityCreator - A script that generates Ant build files that can use to compile our Android

applications. If are developing on Eclipse with the ADT plugin, won't need to use this script.

APPENDIX B

Pseudo-code for AES Key Expansion:

1 expandedKey[0:32] cipherKey[0:32] # copy first 32 bytes of cipher key to expanded key

2 i 1 # Rcon iterator

3 temp = byte[4] # 4-byte container for temp storage

4 while size(expandedKey) < 240

temp last 4 bytes ofexpandedKey

# every 32 bytes apply core schedule to temp

if size(expandedKey)%32 == 0

temp = keyScheduleCore(temp, i)

i i + 1

# since 256-bit key -> add an extra sbox transformation to each new byte

forj in range(4):

temp[j] = sbox[temp[j]]

# XOR temp with the 4-byte block 32 bytes before the end of the current expanded key.

# These 4 bytes become the next bytes in the expanded key

38 | P a g e


39/43

expandedKey.append( temp XOR expandedKey[size(expandedKey)-

32:size(expandedKey)-28]

Appendix C: Glossary

The list below defines some of the basic terminology of the Android platform.

A

Action

A description of something that an Intent sender wants done. An action is a string value assigned

to an Intent. Action strings can be defined by Android or by a third-party developer.

Activity

A single screen in an application, with supporting Java code, derived from theActivityclass.

Application

From a component perspective, an Android application consists of one or more activities,

services, listeners, and intent receivers.

B

Broadcast Receiver

An application class that listens for Intents that are broadcast, rather than being sent to a singletarget application/activity.

39 | P a g e
http://developer.android.com/reference/android/app/Activity.htmlhttp://developer.android.com/reference/android/app/Activity.htmlhttp://developer.android.com/reference/android/app/Activity.html


40/43

C

Content Provider

A data-abstraction layer that we can use to safely expose your application's data to other

applications.

D

Dalvik

The Android platform's virtual machine. The Dalvik VM is an interpreter-only virtual machine that

executes files in the Dalvik Executable (.dex) format, a format that is optimized for efficient

storage and memory-mappable execution.

DDMS

Dalvik Debug Monitor Service, a GUI debugging application included with the SDK. It provides

screen capture, log dump, and process examination capabilities.

Dialog

A floating window that acts as a lightweight form. A dialog can have button controls only and is

intended to perform a simple action (such as button choice) and perhaps return a value

Drawable

A compiled visual resource that can be used as a background, title, or other part of the screen.

I

Intent

An message object that we can use to launch or communicate with other applications/activities

asynchronously.

Intent Filter

A filter object that an application declares in its manifest file, to tell the system what types of

Intents each of its components is willing to accept and with what criteria.

L

Layout Resource

An XML file that describes the layout of an Activity screen.

M

Manifest File

An XML file that each application must define, to describe the application's package name,

version, components ,imported libraries, and describes the various activies, and so on.

40 | P a g e


41/43

S

Service

An object of class Service that runs in the background (without any UI presence) to perform

various persistent actions, such as playing music or monitoring network activity.

T

Theme

A set of properties (text size, background color, and so on) bundled together to define various

default display settings.

U

URIs in Android

Android uses URI strings as the basis for requesting data in a content provider.

V

View

An object that draws to a rectangular area on the screen and handles click, keystroke, and other

interaction events. A View is a base class for most layout components of an Activity or Dialog

screen.

Viewgroup

A container object that groups a set of child Views. The viewgroup is responsible for deciding

where child views are positioned and how large they can be, as well as for calling each to draw

itself when appropriate.

W

Widget

One of a set of fully implemented View subclasses that render form elements and other UI

components, such as a text box or popup menu.

Window

In an Android application, an object derived from the abstract class Window that specifies the

elements of a generic window, such as the look and feel.

Others

.apk file

Android application package file. Each Android application is compiled and packaged in a single

file that includes all of the application's code (.dex files), resources, assets, and manifest file.

41 | P a g e
http://developer.android.com/reference/android/app/Service.htmlhttp://developer.android.com/reference/android/app/Service.htmlhttp://developer.android.com/reference/android/view/Window.htmlhttp://developer.android.com/reference/android/app/Service.htmlhttp://developer.android.com/reference/android/view/Window.html


42/43

.dex file

Compiled Android application code file.Android programs are compiled into .dex (Dalvik

Executable) files, which are in turn zipped into a single .apk file on the device.

APPENDIX D: List of figures

Figure No. DescriptionPage

No.

Fig 2.4.4 Use case Diagram 9

Fig 2.5.1 Test Plan 9

Fig 2.5.2 Use case diagram 10

Fig 3.1.1 Single Tier architecture 11

Fig 3.1.2 Modified application system architecture 11

42 | P a g e


43/43

Fig 3.1.3 Application software architecture 12

Fig 3.2.1 Data flow diagram 13

Fig 3.2.2 Compleat sequence diagram 14

Fig 3.2.3 Deployment diagram 14

Fig 3.2.4 Sequence Diagram for authentication 16

Fig 3.2.5 Sequence Diagram for application access 17

Fig 3.2.6 Main Sequence diagram 17

Fig 3.2.7 Class Diagram 18

Fig 3.2.8 Elaborated class diagram 19

Fig 3.3.1 Use case diagram 19

Fig 3.3.2 Activity diagram for Sending data 20

Fig 3.3.3 Activity diagram for Receiving data 21

Fig 3.3.4 Main activity diagram 21

Fig 3.3.5 State diagram 22

Documents

Security Frame Work for Android