Introduction
Today’s world is becoming more and more integrated, interconnected and intelligent. Mobil devices are playing an ever-increasing role in changing the way and concept of information communication system. Mobile device technology is now blessed with smartphones and tablets. Not only the busy corporate world, but also the regular users of every age are getting involved to them. Employees of various organizations are now bringing their own devices to the workplaces and asking the organization to support them. These new devices offer improved hardware performance, more robust platform feature set and increased communication bandwidth. As a result these increased accesses to the organization’s enterprise system can also bring an increased security risk to the organization. It’s no exaggeration to say that smartphones have become ubiquitous in government and in the population at large, and it’s no wonder. These devices allow users to remain productive, even when walking between destinations, stuck on public transit, or during downtime in meetings.
Modern Generation Smartphones
Modern Generation smartphones generally use ARM microprocessor with clock rates over 1 GB, some models have already arrived in market with dual or quad-core CPUs and even higher clock rates. They have gigabytes of storage and reasonably fast networks. In these respects,current smartphones are faster and better-provisioned than desktop computers from a decade ago. This raises an interesting opportunity because smartphones have more than adequate resources to leverage decades of research into secure operating systems. Smartphones from most vendors can or will soon run full-blown Unix-style operating systems. Smartphones from most vendors can or will soon run full-blown Unix-style operating system kernels. This means that security features ranging from virtualization and secure booting to information flow control and multi-level security can potentially be applied to creating high-assurance software within smartphones.
Data Security Trends
Many stakes of our socio-economical life such as government, military, private and public sectors, IT departments etc are locking personnel out of social sites rather pushing these users to do these activities on personal smartphones. As a result these personnel are using their smart devices to visit social sites. This is eventually increasing more and more uses of smart devices. Application markets are rapidly increasing. There are millions of applications to download. Smartphone users may take the advantage of having experienced with these applications and utilities. All these activities does not keep users from storing sensitive and private information on their deices.
Data Security on Smartphone
Most of the regular smartphone users have some information stored in their mobile phone that they consider sensitive and secret. An average user today has about 25 passwords to manage and if they find difficulties to memorize them, they tend to use weak or easy-to-memorize passwords. Even after choosing easy passwords they usually forget some of them after sometime anyway. These information can be categorized as mobile data.
Types of Mobile Data
Primarily there are three types of mobile data that we can consider on security threats.
- Voice data
- Data in motion (i.e. sending data over an unsecured wireless network)
- Data at rest (i.e. phonebook, message, music list, game score etc)
Data Encryption Service
A single user can be the owner of multiple devices. For example, let us consider a student who is studying Computer Science and Engineering. S/he needs a computer for working on various types of softwares/IDEs; therefore s/he owns a desktop computer. While on having tours s/he wants to read books and listening to music, so s/he bought a tablet. S/he also needs so make phone calls while having tour, so s/he also got a smartphone. S/he uses each of these devices to store various kinds of data and obviously wants to keep some of data encrypted or protected. What our sample user needs is a possibility for storing sensitive data in secured (encrypted) way and to be able to synchronize those data over the network. Our goal is to provide this possibility through an encryption service.
Feasibility Study
An important outcome of the preliminary investigation is the determination that the system requested is feasible. Feasibility study is carried out to select the best system that meats the performance requirements.
Technical Feasibility
The technical feasibility issue usually occurred on the basis of system requirements. The implementation of our thesis work requires Android which is widely available in a variety of platforms. So in a short this we consider that the work will be carried out satisfying the technical feasibility.
Operational Feasibility
The operational feasibility measures how well a proposed system solves the problem. The outcome of our thesis work offers a greater level of user friendly behaviors. As the volume of the work is large, the operational feasibility depends on the success of each module.
Economical Feasibility
Economic feasibility refers to the cost/benefit analysis of a project. To conduct each and every module of our thesis work is economically feasible. Both the development cost and operating cost is tolerable.
DATA SECURITY USING CRYPTOGRAPHY
Data Security Using Cryptography
In this chapter we will discuss about the uses of cryptographic algorithms and functions. Cryptography is typically applied when trying to ensure data confidentiality, to authenticate people or devices, or to verify data integrity in risky environments.
AES Cypher
AES is a specification for the encryption of electronic data that was established and announced by the U.S. National Institute of Standards and Technology (NIST) in 2001. It was developed by two cryptographers, Joan Daemen and Vincent Rijmen. AES is based on a design principle known as a substitution-permutation network, and is fast in both software and hardware. AES does not use a Feistel network like DES. AES has a fixed block size of 128 bits and a key size of either 128, 192, or 256 bits. AES operates on a 4 x 4 column-major order matrix of bytes, termed the state (versions of Rijndael with a larger block size have additional columns in the state). The AES cipher is specified as a number of repetitions of transformation rounds that convert the input plaintext into the final output of ciphertext. Each round consists of several processing steps, including one that depends on the encryption key. A set of reverse rounds are applied to transform ciphertext back into the original plaintext using the same encryption key. The exact description of the cipher can be found in.
Cryptographic Hash Function
A cryptographic hash function is a hash function that takes an arbitrary block of data (message) and returns a fixed-size bit string which is called cryptographic hash value. If any changes are made on data the hash value also changes. The ideal cryptographic hash function implements seudorandom one-way function and has the following four main properties:
- Must be easy to compute the hash value for a given message or data.
- It is infeasible to generate a message that has a given hash.
- It is infeasible to modify a message without changing the hash.
- It is infeasible to find two different messages with the same hash.
The hash functions are useful as they used in various cryptographic protocols and systems. In our thesis work we will use hash function as a tool to improve the properties of random number generation
Key Derivation Functions
A key derivation function (KDF) derives one or more secret keys from a secret value (master key, password, passphrase, other data) using a pseudo-random function. It is very important to know that the strength (resilience against adversary trying to get the secret value) of the KDF depends always on the entropy of the secret value and the difficulty to calculate the function, as adversary can guess the secret value and calculate the derived key.
Cryptography Implementation
To implement the cryptographic functions we decided to use the Open Source Toolkit for SSL/TLS – OpenSSL library. Picking this well-known implementation has several reasons. OpenSSL library is written in the C language which is well suited for the performance of cryptographic functions. OpenSSL is compliant with the cryptographic standard FIPS 140-2 which ensures the quality of the code. OpenSSL contains all the cryptographic functions we will need for our service’s implementation.
SYSTEM ANALYSIS AND DESIGN
Analysis and Design
In this chapter we will discuss about the analysis and design phase of our thesis work. We will first describe the functional requirements and show all the related use cases. Then in the design phase we will demonstrate the components that are related to those functions.
The analysis phase works on the information that are gathered, its builds the logical model of the application. The development of a computer based information system includes a system analysis phase which produces or enhances the data model which itself is a precursor for creating or enhancing the system.
The design phase is the area of problem solving and planning for the system for carrying out the result successfully. The implementation of the designed algorithms along with low-level components. An important topic of software design is complexity management. In practical, software specifications tend to be fluid and change rapidly while the design process is still going on.
The Functional Requirements
It is very important to know the functionality of each and every module of a system from start to end. Functional requirements synthesize the analysis, documentation, validation and managing of a software system. The following are the important parameters directly related to the result of the analysis on our research. s
Storing the Secret Data
The client side application needs to be able to store the secret information in an encrypted way. The user can read, manipulate, and remove the information from the storage in any time. These actions can be carried out only if the user is authenticated, that is the service is unlocked.
Data Storage Safety
The storage repository must be password protected. Here we can define the situation in two stages. After authentication that is, after entering the password the service is said to be ‘Unlocked’. It can be remain unlocked for specific a period of time, after that time it goes to the stage of ‘Locked’. Note that, no operations are allowed when the service is locked.
Synchronization
As the secret data sharing is taking place among various Android devices owned by a single user, the service must provide a synchronization function.
The Use Case Diagram Analysis
This section we will describe the use case diagram. Use case diagram can be used to describe the functionality of a system in a horizontal way. In our research we can divide the use cases into two groups depending on the actor’s interaction to the service. The use case diagram can be used to describe the functionality of a system in a horizontal way. The use case diagram is considered as the blue print for a system. Depending on the variation of the actor and module use cases can be divided into many groups. According to that point we can define two major sections of use cases in our research.
The Application’s Use Cases
In this section we will discuss how the application, that is, the client application which is stored as an app in android OS environment can interact. What are the basic functions that are being done by the application itself will be shown through the diagram. Note that, the application itself will act as an actor in this section.
Checking the Service State
To initiate the client application to work, first of all a checking is needed. The application must check that the service is currently unlocked or not. The application sends a request to the service, and eventually the service replies to it. This checking portion is needed for the application to work with the next states. If the reply is a true, only then the application can work on the next steps. This activity has a sub-task, that is, entering the password. We are defining this as a sub-task, because the initialization process can be done if the encryption service is unlocked.
Storing Information
Information storing is done by an encryption key. The application sends the message along with the key. The service then processes the message and encrypts the information and stores the information under the key. Now there exits an important checking. If the provided key already exists, then the service replaces the newly arrived information with the older one. If not then the service makes a new entry and stores the information.
Manipulating Information
The manipulation of the information mainly includes ‘Reading’ and ‘Deletion’ of the information. For reading, the application asks the service to read the information, the service then decrypts the data and then returns the result. For deletion, the application the application asks the service to delete the data; service then deletes the encrypted data and marks this information as removed, that is not readable anymore.
Uploading Data
When the application asks the service to upload the data, the service uploads all the changed information or new entry to the server after it connects to it.
Downloading Data
Same as the previous section, the application sends a message to the encryption service to ask for downloading the data. The service then connects to the sever and downloads the available updates of the information.
The User’s Use Cases
The person who is handling the client application on android OS environment is considered the actor in this section of use cases. We can also define this actor as the user of the system.
Initializing the Service
After successfully installing the android client application package it is now ready to use. The user initializes he service by invoking it. The service becomes ready to use. The user settings along with the password are both set to their default values.
User Setting Management
Having successfully initializing the service the user may want to change the settings such as password setting. To do so, the user finds the preference settings and then provokes the service for password setting. The service then prompts the user to put the old password then ask the user to put the new password again ask the user to retype it. If the process is successful, then the new password is set.
Synchronization Setting Management
There are two synchronization states, they are, uploading data and downloading data. After initialization, the user may found the synchronization setting in preference section of the client service. There the user can alter the synchronization service (uploading / downloading data) according to the user’s own need.
Finishing Service
In preference section the user can also find the option for termination or finishing the service. If the user chooses to terminate the client service, then the encryption service switches itself to a state which is no longer usable by the client application. This can be considered the finishing or destroying of the service.
Components Analysis
We can describe our implementation as a collection of components too. These components will work together to cover up all the necessary functionalities to successfully complete the service. The following diagram shows the components and their responsibilities to each other and android OS also.
As described in the above diagram the components can be divided into two major categories, they are:
- Server side application components
- Client side application
Server Side Application Components
The server side component contains some other services. There must an encryption library for transforming the client’s secret data or information. In additional a mailing library will be needed to support the synchronization. To keep track of every secret information we will need SQLite database.
Client Side Application Components
To support and communicate every client application will an android application. Secret data information from client’s will be outputted into file system, so there will be need for access to the filesystem too. The most important point here is that any application will be service’s client application. By using the right set of information the user of the phone does no longer have to worry about the data insecurity.
IMPLEMENTATION
In this chapter we will discuss how our services can be implemented. We will start our discussion on android ‘Activities’ and ‘Services’. We will also take a look on the background services and all other possibilities related to the implementation.
Android Activity and Service
We can define application components as the essential building blocks for our service. All components are not the usual entry point for the user and some can be dependable on each other, but the important fact is each one exists as its own entity and plays a specific role. There are four different types of application components: Activities, Services, Content providers and Broadcast Receivers. Two of the four were used to develop the encryption service: Activities and a Service. We will now shortly describe each of these two components.
An activity simply represents a single screen with a user interface. Although all the activities work together to form a complete application solution, each one can be independent from each other. An important thing is different application or application part can invoke any one of these activities. In android an activity is implemented as a subclass of Activity class.
A service is a component that runs in the background to perform long-running operations or to perform work for remote processes. A service does not need a user interface. For example, a service might download a file from internet while the user is in a different application.
Using Intents for Starting Activities and Services
As there is no main() function in android so android applications do not have a single entry level. Android gives us a more powerful feature that is any application can invoke another application’s components. There are several permissions that restricts to access one application’s components to another. To activate a component every application needs to pass messages to the system, these messages are called intents. Intents are basically objects which specify the URI of the data to at on. For example, a URI of an image to show by an image viewer application, or a URI of web content sent to a web browser. There are two methods o activate an intent. They are:
- startActivity, which is used when you don’t want a result to be returned. This is a one way flow of activity invocation.
- startActivityForResult, this is used when you want an activity to return a result. This a both way communication between activities as the returned data can be manipulated bye the caller activity.
Filtering the Services
To make the services available to the application it is necessary to declare the services first. To support this, a listing of the intents can be done. In android the list of all activities which can be invoked by the intents are listen in android’s ‘AndroidManifest.xml’ file. The OS reads it and prepare classes that would be used as activity. Also the manifest decides which class can be called as the launcher activity.
Service Initialization
Initializing an application means getting it into a default state and let the user to run and invoke. For additional default state android offers ‘SharedPreferences’ to store application values. For example a game application can store high-score in sharedpreferences. For our service a default password is set in initial state. Finally a default name value is set.
Building Encryption Operation
We will go for the AES encryption tool that can be used on android platform. Though there exists several C / C++ AES library, we will go for Java’s built in ‘Cypher’, ‘KeyGenerator’ etc to provide AES and its property. In addition to our implementation we can also have a look at android’s powerful NDK. The Android NDK is a companion tool to the Android SDK that lets us build performance-critical portions of our apps in native code. It provides headers and libraries that allow us to work with the Android OS. One can handle user input, use hardware sensors, access application resources, and more, while programming in C or C++. The fundamental Android application model does not change, the application is still built in an .apk file and the application still runs inside of a virtual machine on the device.
The Functionalities
In our analysis part of our thesis we described about the basic functionalities that our service must meet. The following section describes the approaches and behaviors of these functions.
Storing Data
When the user asks the service to store secret data a random salt bite is generated in cryptographic stage. The same bytes can be used to read when decrypting the encrypted data. The java.security.* packages can be used to perform this operation. The bytes of the secret information is then sent to OpenSSL for encryption. At last the changes are arranged in SQLite database. There can be two situation:
- The secret information is new, so a new row is added to the table.
- The secret information is not new. In this case the respective table row is updated.
Reading Data
When the user asks the service to read a data that was previously stored, the controller first locates the file with the secret key. Then the first eight bites are read which we call the salt bites. The remaining bites are decrypted and returned back to the calling user.
Deleting Data
When the user asked the service to delete the secret data, the controller finds the encrypted file and deletes it from the filesystem. Their raises two conditions with the deletion situation.
- The secret information has never been uploaded – the uploaded _eld is false, thus the deletion does not have to be uploaded.
- The secret information has been uploaded before – the uploaded _eld is true, thus the deletion need to be uploaded the next time the upload operation is invoked by the user.
Destroying the Service
User can either destroy the application or uninstall the whole application from the system. In general an exit button exist which contains a click listener, in that click listener call back the application destroy function that is finish() is called. The calling of finish method invokes the android onDestroy.
Invoking the Services
With the help of remote procedure calls (RPCs) android offers interprocess communication which remotely executes an activity of other application and brings back the result to the caller. This discussion is necessary as our service runs in background and listens for any request that comes from client application. The service and application can exchange messages as soon as they get bound. RPCs are useful as they provide synchronous communication.
The Basic of Upload and Download Operations
For the upload-download operation we need JavaMail library. Eventually these operations will need another uses permission in android’s manifest and the permission is INTERNET. All IMAP and SMTP preferences have to fill correctly in order to connect to the mail servers successfully. If any of the previously mentioned requirements are not fulfilled, the user is informed about the problem and a called operation does not carry on.
Service Preferences
There are several preferences that we should provide for the end user so that the user can use the total application in a correct way. The following are the preferences that can be compatible to provide to the user.
- Password – Our service start with a default password which can changed or removed by the user. All the flow of secret information is done using this password, so it is logically important for the user to provide a strong password.
- Password validity – There can be a time period after which the entered password is expired. The user then have to put a new password along with the old one. The new password replaces the older one.
Error Reporting
In addition to the above discussion we should provide the user with an error reporting system. Testing an application thoroughly prior to releasing is of course a very important part of the development process, but errors usually do occur anyways. Different errors may show up when using various devices or operating system versions. The total number of different Android device models has quickly gone from tens to hundreds and it has become impossible for a developer to have them all in order to test their application on each one of them. Getting error reports from those users to developers is the only way how issues can be taken care of.
SECURITY SOLUTIONS AND COMPARISON
Security Solutions and Comparison
In this chapter we will discuss about the existing security solutions for mobile devices and some comparison between them and our application service.
Existing Available Solutions
There are very few numbers of open source and commercial solutions available in marketplaces. As the mobile devices and their market places are still in positive growth, its is very hard to find a security solution that we proposed in our thesis work. Among the most famous ones is an open-source solution called TrueCrypt, which offers automatic, transparent, real-time (on-the-fly) partition or drive encryption.
Comparison with Our Own Service
In our provided service data is always secure while the service is unlocked. Data protection is occurs in same way when the phone remains switch off or not. Moreover it will cause no hamper to the local file system (sd card occasionally). Finally as we are using an encryption system, data and user request is remains in safety. Everything is done automatically so the user illogical input exception reduces.
Modern Cloud Storage Concept
In modern storage concept storing data in clod storage is getting popularity day by day. Many of them do not provide client-side encryption though. Among them DropBox or Box, Google Drive are most popular. Another concept is very useful for the developer with large scale of developing team who are diversified worldwide. They are usually called versioning system. In recent years Github, BitBucket etc are getting popular. They provide Git repository to connect, push, pull, merge, delete etc on the project files. Also provides history of committing each time which helps to find out the changes that are made.
Comparison with Our Service
As in our service we are providing data flow with update, new entry insertion and deletion we can compare these actions to the repository system that we described earlier. A disadvantage or limitation of the service is that if the user need more that one type of information, more that one application is required.
RESULTS AND CONCLUSION
Results and Conclusion
In this chapter we are going to conclude or summarize our achievements and proposing some enhancements for further interest.
Achieved Results
This project was initiated for a couple main reasons. The first one is that we decided to improve personal data security on a user’s device. The other main reason was that we as developers wanted to gain new programming experience. The objective was developing a service that can be implemented on very new technology like android embedded system as android platform is expanding and becoming a powerful and popular working field for the developers. Also the objective of this thesis work was to design a service that can run in background that is capable of connecting to other components of one or more activities. Before working on this topic we have no vast knowledge on android so that we could design such a large and robust application concept. During the implementation we had to learn about Android components (activities, services), delivering intents etc.
Considering the above gaining we can say that the achieved results of our thesis work gains success in various dimensions. Working of the thesis surely enriched us of some Android development skills and the expectations were met. We hope this work with all its concepts, ideas and design will be helpful to the others.
Possible Enhancements
The following are the list of possible enhancements that can be implemented in future if they are technically feasible.
- Support for different platforms, for example Windows, Mac, Linux etc.
- Data sharing among different users. If the service can be made available for different platforms, there will be different users with different OS. So synchronizations must be done.
- Various authentication methods can be applied such as biometrics authentication.