Potential for Data Loss from Security Protected Smartphones

Smartphones have been widely accepted by mass market users and enterprise users. However, the threats related to Smartphones have emerged. Smartphones carry substantial amounts of sensitive data. There have been successful attacks in the wild on jail broken phones. Therefore, smartphones need to be treated like a computer and have to be secured from all types of attacks. There is proof of concept attacks on Apple iOS and Google Android. This project aims to analyze some of the attacks on Smartphones and find possible solutions in order to defend the attacks. Thereby, this project is based on a proof of concept malware for testing antivirus software.

Text sample:
Chpater 3.3, Security features of Google Android:
Android uses non-standard Java platform called Dalvik and Linux. Programs are written in Java and then compiled using Google tools. Android is open source, which makes it open for security scrutiny by experts. One reason why Android has less vulnerability is because of its openness which allows security experts to scrutinize the code for security flaws.
I. Access control: Android s access control is similar to iPhone. It can be configured for maximum number of login attempts, wipe the device after certain login attempts and password strength. Android allows administrators to configure how often the login password should be changed.
II. Digital signing of applications: Application signing for Android is not rigorous as Apple. Anyone who wishes to develop an application for Android does not have to obtain certificate from Google, they can create their own certificate, develop an application and publish it in the Android market. A malicious developer can create a certificate by providing fake information. This is one reason why there are more malwares and Trojans for Android. Unlike Apple, Android does not verify the application before it is published. Android checks the application when it is reported to be malicious and removes it from Android market once it confirms it. Developers have to pay $25 to Google using a credit card, the credit card details is only the way to associate a developer to an app. However, a malicious developer might use someone else s credit card to save their identity. Android also allows users to download and install apps from internet and external SD card.
III. Encryption: Android introduced Encryption which uses AES 128 with CBC for tablets from Android 3.2 which is also called as Honeycomb [38]. It is a Kernel level implementation. However, Android for Smartphones does not support encryption. This is a potential risk as anyone with physical access to the device can read the data from the memory card bypassing the access control mechanism.
IV. Isolating processes or Sandboxing: While applications for Android are written in Java, Android does not rely on Java s sandbox feature to isolate applications it has its own application isolation policy. Android implements a stringent isolation policy in such a way that no application is allowed get administrator or kernel level access. Every application runs in its own sandbox and has the rights that it is allowed. An application cannot access data of another application however; an application might invoke another application. For example, when a user accessing email using the email application clicks on a web link, the email application invokes the web browser application. If a malware exploits a vulnerability of an application, the attack is limited to the application. A malware cannot affect other applications or nor can it get administrator or kernel access thus blocking the malware from infecting other applications. However, if an application like a web browser is exploited by malicious code, it can steal information such as browsing history, form data like password and credit card details, etc.
V. Permission based access control: Android implements a strict permission based access control policy for applications. An application cannot be installed silently with user notification. User interaction is required to install any kind of application which prevents a lot of drive by download attacks. Android maintains a list of permissions an app is requesting. It displays the access permissions requested by an app to the user, if the user chooses to agree and install, the app is installed. If the user wishes to abort the installation, the application is not installed.