Storing Encrypted Plain Text Files Using Google Android

Jared Hatfield University of Louisville

Abstract
Google Android is an open source operating system that is available on a wide variety of smart phones from a variety of manufactures. While the core operating system uses encryption for phone calls, web browsing, and email, the local storage available on the phone is primarily unencrypted. Encryption can be deployed at the application level to protect data stored on the phone. On a typical device, the data for an application is stored on the onboard micro SD card which can easily be mounted on a computer. The files stored on the card can then be copied to another device for analysis. If an unauthorized party were to gain physical access to a phone, it would be possible to quickly create a copy of the onboard data, potentially without the phones owner even noticing. A simple notepad application that uses an encryption algorithm and user provided password can be used to read and write plain text securely to a file on the SD card. The security of the information stored using this approach will be analyzed and the method deployed will be documented.

1. Security and the Android Platform

Based on the Linux kernel, the Android Open Source operating system is a mobile phone operating system that has rapidly gained popularity following the success of Apples iPhone. With the first public release in late 2008, Android has undergone rapid development and has gained wide spread adoption by major phone manufactures and wireless carriers. Unlike other major mobile operating systems, Android is an open source operating system meaning every bit of the operating systems code is freely and publically available for inspection, modification, and reuse. The main goal, when it comes to security and the Android platform, is outlined on the developers web site, An application's process runs in a security sandbox. The sandbox is designed to prevent applications from disrupting each other, except by explicitly declaring the permissions they need for additional capabilities not provided by the basic sandbox. (Google, 2010) The threat model addressed focuses on preventing malicious applications from the market place or code downloaded from the internet from compromising the phone. For the purposes of describing the threat model addressed, we will assume that Alice has a phone running Android and Oscar is actively attempting to gain access to the content stored on Alices phone. The specific threat addressed is securing information should Oscar obtain physical access to Alices Android based phone, even if only for a short period of time. It would be possible to copy files off of the phones storage using a standard computer, a task which can take only a few moments. While the online accounts that are likely authenticated on the phone could be targeted, they are not the focus of this study. 1

2. Storing Information Securely

The typical Android based phone includes internal flash memory and a removable microSD card that provides additional storage on top of the built in storage. The information stored on the phone, in general, is unencrypted. Even if a password or unlock pattern is used, it is possible to remove the microSD card from the phone and mount the partition on a computer and gain access to the information stored on the card. However, Android provides a simple mechanism for mounting the microSD card using the phones interface making the task even easier. Applications developed for the Android platform are written in Java and target the Dalvik virtual machine. This allows the applications to be independent of the underlying system architecture. Every application on the platform is sandboxed to prevent unauthorized cross application leakage. When an application is installed the permissions that the application requires to run are presented to the user and must be authorized before the installation will continue. The microSD card serves as a common storage location that is accessible from any application authorized to access the extended persistent memory.

3. Storage of Encrypted Text Files

A simple Android application, OpenNoteSecure has been developed to illustrate a method for storing encrypted text files on the phones microSD card. Android provides access to many of the standard Java libraries including javax.crypto which includes AES and DES symmetric encryption ciphers.

3.1 Encryption Implementation

Figure 1

The method employed for encryption and decryption is a two stage process as outlined in Figure 1. The text field that is provided to the user is editable in a String representation. This plain text string is encrypted using the specified cipher and password before being encoded as a Base64 2

string and written to a file. For decryption the process is reversed and the file is read and converted into the raw cipher text from the Base64 encoding and then decrypted using the specified cipher and password before being displayed to the user. The Base64 encoding is not required from a technical standpoint, but allows the encrypted text to be viewed in its encoding form using the same editor that was used to encrypt the text. An example of an encrypted string is shown in Table 1.

Plain Text String Password Encrypted AES String Encrypted DES String

The encrypted text. mypassword k8xP+cNbq1XglWZ9a0X5F2cw6HZXlev5zs7ObiL6pak= 7VEYR6414dZET24jh8Gx2VoCZqXdmHJe Table 1

3.2 Android Application GUI

Figure 2

Figure 3

Figure 4

The graphical elements for the interface are simple and provide the necessary functionality to encrypt simple notes. Figure 2 depicts the initial interface that allows for the creation of new files and displays all *.txt files that currently exist in the root directory. When a file is selected the next interface as seen in Figure 3 is displayed. This allows the user to select the encryption algorithm and input the password for the file. For new files, the encryption algorithm and password will be used when the formerly empty file is saved. The last interface, as seen in Figure 4, provides the means to view, edit, and save the text back to the file.

4. Analysis of Security
Software that uses encryption to store information must be carefully constructed so that it minimizes its surface for attack. Since it is necessary to decrypt the file on the device, it is unavoidable to have the decrypted text to be stored in RAM so the plain text can be viewed and manipulated.

4.1 Encryption Ciphers

The Android platforms primary language for creating applications is Java. While the language for writing applications follows the Java syntax, the language itself does not strictly follow the standard Java implementation and not all of the standard libraries are available. However, the javax.crypto.Cipher library is available and can be used to perform AES and DES encryption. The following code sample shows the constructor and encryption routines that are used to perform the AES encryption. The AESEncryptionProvider class provides a constructor that takes a string passphrase and then provides two methods encryptAsBase64 and decryptAsBase64 which are part of the IStringEncryptor abstract class that allows for the encryption algorithm to be interchangeable.
/** * Constructor for AESEncryptionProvider for a specific passphrase * @param passphrase The phassphrase to protect the data with. * @throws EncryptionException */ public AESEncryptionProvider(String passphrase) throws EncryptionException { // Set up the cipher this.CIPHER_TRANSFORMATION = "AES/CBC/PKCS5Padding"; this.CIPHER_ALGORITHM = "AES"; this.MESSAGEDIGEST_ALGORITHM = "MD5"; // Create the password byte array byte[] passwordKey = encodeDigest(passphrase); // Set up the algorithm try { cipher = Cipher.getInstance(CIPHER_TRANSFORMATION); } catch (NoSuchAlgorithmException e) { Log.e(OpenNoteSecure.TAG, "No such algorithm " + CIPHER_ALGORITHM, e); throw new EncryptionException("AESEncrpyionProvider could not be created", e); } catch (NoSuchPaddingException e) { Log.e(OpenNoteSecure.TAG, "No such padding PKCS5", e); throw new EncryptionException("AESEncrpyionProvider could not be created", e); } // Finish setting up the encryption by making the secret key and iv parameters secretKey = new SecretKeySpec(passwordKey, CIPHER_ALGORITHM); ivParameterSpec = new IvParameterSpec(rawSecretKey); }

The AESEncryptionProvider constructor takes a pass phrase and converts it to a secret key that can be used to encrypt or decrypt text using the appropriate methods. The primary responsibility of the constructor is to simply create the key; once the key is created, the encryption provide is able to function.

/** * Performs the encryption on a string of data * @param data The plain text to encrypt. * @return The encrypted text encoded as a Base64 string. */ public String encryptAsBase64(String data) throws EncryptionException{ byte[] encryptedData = encrypt(data.getBytes()); return Base64.encodeBytes(encryptedData); }

The public encryption method used to encrypt a string provides a simple mechanism that returns the encrypted cipher text as a string. To accomplish this the underlying encryption algorithm performs the manipulation on a byte array computed from the original plain text string. To convert this byte array back to a string after it is encrypted, it is encoded as a Base64 string using a freely available encryption library provided by http://iharder.net/base64.
/** * Performs the AES encryption on a byte array. * @param clearData The unencrypted byte array. * @return The encrypted byte array. * @throws EncryptionException */ private byte[] encrypt(byte[] clearData) throws EncryptionException { try { cipher.init(Cipher.ENCRYPT_MODE, secretKey, ivParameterSpec); } catch (InvalidKeyException e) { Log.e(OpenNoteSecure.TAG, "Invalid key", e); throw new EncryptionException("AESEncrpyionProvider could not be created", e); } catch (InvalidAlgorithmParameterException e) { Log.e(OpenNoteSecure.TAG, "Invalid algorithm " + CIPHER_ALGORITHM, e); throw new EncryptionException("AESEncrpyionProvider could not be created", e); } byte[] encryptedData; try { encryptedData = cipher.doFinal(clearData); } catch (IllegalBlockSizeException e) { Log.e(OpenNoteSecure.TAG, "Illegal block size", e); throw new EncryptionException("AESEncrpyionProvider could not be created", e); } catch (BadPaddingException e) { Log.e(OpenNoteSecure.TAG, "Bad padding", e); throw new EncryptionException("AESEncrpyionProvider could not be created", e); } return encryptedData; }

The majority of the code surrounding the encryption and decryption routines is a try/catch block. The crypto routines are capable of throwing various exceptions in the case where the encryption or decryption fails. These routines catch these exceptions and then throw a new exception called EncryptionException. The EncryptionException is a new type of exception that simply indicates that the encryption or decryption routine was not able to be executed successfully. The main reason for throwing this exception is the instance where the wrong algorithms or password is used to attempt to decrypt a file. In this case the file is not decrypted and an error message is 5

displayed. The actual execution of the encryption is very simple to invoke and the complexity is masked by the underlying libraries.

4.2 Password and Key Distribution

The simplest approach to securing the encrypted files is to not store the password on the device itself. Were the password to be stored on the device it would be possible to decrypt the file if the device would fall into Oscars hands. The limitation to this approach is that the password must be memorized by Alice. Additionally, the password must be entered using a mobile on screen or physical keyboard which has limitations on the methods of data entry. These limitations may frustrate users. Assuming Alice uses a strong password to encrypt her information the encrypted information will be secure. When the file is being edited it is stored in memory as plain text along with the password that was used to for decryption. The Dalvik virtual machine relies on a garbage collector to free the allocated memory. Additionally, Android allows for multitasking so the application may still be running in the background after the user navigates away from it. This results in a period where the plain text is stored in the phones memory, even if the application is not in the foreground. However, steps can be taken to minimize these risks.

4.3 Limiting Exploitation Window

The sensitive information that is stored in memory can be limited to the password and cipher text. The other information including the selected file and algorithm are not as sensitive. To limit these risks, the information needs to be removed from RAM as soon as it is no longer needed. Using the virtual machines garbage collector, this can be, at least partially, accomplished with little effort. By removing all references to sensitive strings and then invoking the garbage collector the sensitive information in RAM would quickly be lost. However, there is no guarantee that the garbage collector will actually be invoked and that the contents of the RAM would be overwritten with new information.
/** * Remove references to sensitive information and suggest the * garbage collector runs before finishing the activity. */ private void PerformCleanupAndClose(){ // Remove all of the references to the sensitive variables this.content.setText(""); this.password = ""; // Tell the system we want to run the garbage collector System.gc(); // Close this activity this.finish(); }

5. Future Work
The initial release of OpenNoteSecure is capable of performing symmetric encryption. The ability to perform asymmetric encryption would be very useful for securely encrypting 6

information that would be transmitted from user to user. The difficulty in implementing a system for performing asymmetric encryption arises from the vulnerability of the key store. The private keys that would need to be stored on the mobile device would need to be protected, which could be accomplished with a symmetric cipher and a pass phrase.

6. Conclusion
The built in mechanisms for securing application data on the Android platform are currently limited, but the ability to secure information on an application by application basis has existing potential. The information stored on a mobile device depends on the security of the passphrase that is used to secure the information. The main issue is the compromise between security and convenience. In practice the convenience of easily accessible information wins over the ability to securely store this information. As a result, the main concern is using strong encryption keys that do not require memorization and manual entry from the user. OpenNoteSecure demonstrates that data security can be achieved, but still depends on memorization of keys by the user.

Resources
The source code for OpenNoteSecure is released under a General Public License Version 3. http://github.com/JaredHatfield/OpenNoteSecure OpenNoteSecure is available to download for free from the Android Market. com.jaredhatfield.opennotesecure

Works Cited
Google. (2010, June 23). Security and Permissions. Retrieved from Android Developers: http://developer.android.com/guide/topics/security/security.html