[Android Software Development] lolo250612:
Quick encryption guide (and more)

I won't go deep into useless details as everything has already been described about Android phone protection somewhere on the internet. I will just give some meaningful links and tips by illustrating how I have protected my phone. Really nothing new or innovative, just a compilation of a few hints that I have put in practice to protect the numerous pieces of information that are on my phone.

Step 0: awareness

----------------------------

Why bother with phone security?

In short, I am clearly paranoid. Well, in fact, I don’t really feel at ease when I know all the information, both personal and professional I have on my phone. Over the month, my Androphone has become a real digital Swiss-knife and personal secretary. This includes:

Personal and professional contacts

Personal and professional agendas

Personal and professional digital exchanges (SMS and email)

Personal and professional photos

Banking account information

Trails where I run

Etc… etc…

Don't want someone looks at them. Not you?

Fist step: on-line protection

----------------------------------------

The first step in protecting your data consists in making hard to access indirectly the data that lay on your phone memory. This access consists in using the system when the phone is on, either via the GUI and the phone controls, or remotely (essentially by network connections, or phone basic functionalities like sms). So, basically, you need to lock efficiently your phone from preventing someone else to unlock the user interface that allows interactions with the system, and protect all communication channels.

To lock efficiently your phone, you must use a pin code of at least 4 digits (6 is better) or a pass-phrase. The latter is much less practical without improving online security that much. Above all, you must avoid those silly locking solutions like face recognition unlocking, or pattern lock. Those are toys for naive young boys. Not for those concerned seriously by security.

For protecting remote access to your phone, I would suggest:

1) Double check that USB debugging is disabled. This a major security hole.

2) Turn on data connections (bluetooth, wifi and 2/G/3G/4G) only when required (email checking, web-surfing session, data synchronising), and off rest of the time.

3) Avoid install cracked unofficial apks, or applications that asks for permission far beyond their obvious and principal utility

4) Install a software security app, if possible, open source and recognised by xda members. Once an adept of Droiwall, I have switched to Avast mobile security because of its extra features. But it is not opensource and it is a question of taste. But do this carefully, see that for instance before making a choice: http://download.cnet.com/8301-2007_4-57391170-12/dont-get-faked-by-android-antivirus-apps/ and http://www.av-test.org/fileadmin/pdf/avtest_2012-02_android_anti-malware_report_english.pdf.

But, you must be rooted (which is in itself a security hole if not mastered) and one must have a kernel with netfilter functionalities activated. This is the case with the stock kernel of the phone I use at the present time (Lenovo A789). But was not the case of 2 Samsung phones I used before. You have to either install a custom kernel adapted to your phone, or make your own if you have access to its sources (see tutorials as: http://xdaforums.com/showpost.php?p=22941057&postcount=1)

5) Personally, I would feel more at ease if I could find an easy to use firewall solution that could close, and better, make stealth all the local ports of my phone, especially when I am not behind a wifi router. But I haven’t found one yet. Droidwall, nor Avast, addresses this functionality, whereas it would be fairly easy to implement it with the netfilter system layer underneath.

Second step: offline protection

-------------------------------------------

Here we are. Now your phone is protected when it is on. But, what if you switch it off, or remove its sdcard? The data lay on the internal memory, unprotected (at best obfuscated). Really easy to find a custom recovery for almost all phones, write a script to dump /data on a sdcard and then make whatever you want with the copy.

Don’t like that? The only solution to prevent /data from being read by someone else is to encrypt the /data partition. To do that, your phone or tablet internal storage partitions must be seen by your system as block devices. This is the case with eMMC but not with Yaffs. So beware, if you want encryption you need to buy a device that answers this requirement. This is not always true and almost never documented. Notes on the implementation of Android encryption are there: http://source.android.com/tech/encryption/android_crypto_implementation.html

Now, as me, if you are reading these lines, you are certainly looking for extra information about your Android device and probably extra functionalities.

Certainly, the most frequent way to install extra functionalities and custom ROMs to your phone is to use an update zip file. With stock recovery, this zip file needs to be signed, otherwise it is rejected. For maximum flexibility and ease of use, alternative boot recovery have been developed, of which CWRP is certainly the most famous.

Usually, for 99% of users and operations, CWRP operates great. Sometimes, as nothing is perfect, a bug may occur. This is the case for built in ICS encryption process. As Cybermaus indicates in the first post, to be able to perform this encryption the /data filesystem must be slightly smaller than the underlying partition. But CWRP, at least up to the version 5.5, formats all the corresponding partition leaving no place for Android to store the required information to be able to start the encryption process. This is clearly described in the following links: http://xdaforums.com/showthread.php?t=1792101 and http://rootzwiki.com/topic/25652-fixing-galaxy-tab-2-encryption/

I have discovered that by using aLogcat to track down the origin of the failure. The interesting part revealed to be: E/Cryptfs ( 87): Orig filesystem overlaps crypto footer region. Cannot encrypt in place.

To circumvent this problem, you will find in Cybermaus first post, two CWM update zip files that will do the trick in a simple and secure way. After flashing your ROM and wiping data with CWM, apply them, go to system encryption as described here:http://support.google.com/android/bin/answer.py?hl=en&answer=1663755, and after waiting one or two minutes (not more), the system should restart automagically to encrypt your /data partition.

Third step: making your phone even more secure and practical at the same time

-------------------------------------------------------------------------------------------------------------------

Android built-in encryption is in fact more or less Linux LUKS (http://en.wikipedia.org/wiki/Linux_Unified_Key_Setup). Plus, it is open-source so that everyone with the required skills can make an audit of the code to see if no security hole is present in the Android implementation. The underlying mechanism is strong and secure, as long as you use a strong password. I mean by strong, at least 12 characters that includes at the same time lower-case letters, upper-case letters, numbers and symbols. And it must be something impossible to guess for others while easy to remember for yourself. You will find a lot of resources on the internet on how to create such a password. For instance: https://help.ubuntu.com/community/StrongPasswords .

The problem with Android, in its attempt to keep the system not too complicated to use, is that the GUI (I insist: only the GUI, not the system) does not distinguish between the PIN or passphrase that you use to lock your phone when it is on, and the password used to encrypt the data that lay physically on your phone storage. So the casual user is in front of a paradigm: either he chooses a strong password for its data, but this will rapidly become tedious to type at least 12 characters to unlock his device several times a day; or he decides to use a PIN code, which is more practical to unlock the phone, and consequently uses a really weak password to encrypt its data which contains only digits, and thus may be cracked in a breath by any PC.

Fortunately, this paradigm is addressed and solved by small tools like EncPassChanger or Cryptfs Password (both requiring that your phone be rooted, which is by the way, paradoxically, a security hole if not used with caution ;) ). See: http://nelenkov.blogspot.fr/2012/08/changing-androids-disk-encryption.html for complete notes about that. So for me, the only way, both secure and practical, to secure your phone is by using a PIN code of at least 4 numbers (6 is better). Then use a handy tool like EncPassChanger to have a true complex password for decryption at boot time.

Fourth step: increase security, without sacrifying practicability

-----------------------------------------------------------------------------------------

As I am paranoid, but at the same time don’t want my phone to become a source of annoyances, the previous “basic” steps were not enough for me.

So I decided to improve security in two ways:

1) By following the following tip, which I find great and is itself self-explaining: http://xdaforums.com/showpost.php?p=26730989&postcount=2

2) By encrypting the photos I take with my phone, because these are linked with my private life and I won’t like that somebody gain access to them.

3) By encrypting documents I scan with CamScanner, for home and work, which may be sensitive.

4) By automating the action that disables USB debugging in case I forget to put it off after using it ;).

For point 2 and 3, documents lay on your sd card uncrypted. Android built-in encryption does not deal with both internal and external sdcard (just to be clear, by sdcards I mean partitions mounted as /mnt/scard or /mnt/scard2). To encrypt them you have to use once again an external tool. As I am an opensource fanatic for all that deal with security, I would recommend to use LUKS Manager (https://play.google.com/store/apps/details?id=com.nemesis2.luksmanager&feature=search_result and http://xdaforums.com/showthread.php?t=1141467) which is based on dm-crypt module (yes, the same that Android uses for its build-in encryption), or Cryptonite (https://play.google.com/store/apps/details?id=csh.cryptonite&feature=search_result) which is completely open-source and implements the rock-solid Linux encfs on Android.

The latter is my personal choice. I do not use Crytonite in itself, except for creating the initial .encfs6.xml file. For everyday use, I use directly the Android port of the binary file encfs that comes with Cryptonite, and embed it into shell scripts. Up to now, no flaw, no problem. The password to open my encfs encrypted volumes is stored in a text file located on the /data partition. It is thus encrypted by Android and made accessible on boot when you decrypt this partition. So nothing more to remember.

To make things usable and practical, I use Tasker to automate the following things:

- Mount encfs volumes on start-up, by reading directly the password in the file located on /data

- Umount encfs volumes when usb is plugged

- Copy photos on a regular basis from the unencrypted /mnt/sdcard/DCIM to the safe place I created with encfs, delete AND wipe the original ones

Fifth step: be coherent about security

-----------------------------------------------------

Some people, torn apart by the paradigm described in Third step, by negligence or by lack of knowledge, strongly secure one part of the system, but make other parts big security holes.

Concretely, I am thinking about two examples: mixing encryption with pattern lock (or, even worse, with face unlock), or mixing encryption with usb debugging. Face recognition is just a jock. It is not reliable and fails very often. Moreover it is really easy to crack, with a photo for example. One of my colleague even achieved to unlock my phone with its own face, just because we are morphologically close enough. Pattern lock is not much better. (See: http://xdaforums.com/showpost.php?p=37649447&postcount=6 and https://www.google.fr/search?q=smudge+attack).

So always ponder over (two times rather than one) each action you take that may touch system security.