Introduction
Recently I acquired an HTC HD2 smartphone. It is running Android from NAND. To be specific, the HD2_NDT_MIUI_GINGER_STABLE_V2.2_MAGLDR rom found at XDA. It is known Android isn’t quite secure in terms of physical access. It is inevitable to loose ones mobile device. When that happens we should rest assured the information on that device is not accessible by others.
Approach
There are several ways to solve this problem. But I opted to use cryptsetup because 1) I’m familiar with it 2) transparency: an encrypted container accessible by normal apps 3) portability: the raw container can be opened on other Linux systems.
The first problem is cryptsetup is absent on a standard Android system. Thanks to this post I could get a hold of a binary(ideally one should compile their own). cryptsetup must be pushed to the Rooted device with e.g. adb push
I put mine in /sd-ext/bin which is an ext2 partition the sdcard together with crypt.sh (found lower in this post, inspired by this). The script by default creates a ~1.8GB container on the sdcard called crypt.raw and the mount point at /sdcard/crypt.
Usage
First the container must be initialized. This can be done within adb shell:
It will take a while depending on the container size.
After it’s done you can mount the container:
and unmount:
What if we’re away from a computer without access to adb? Simply use connectbot to open a local connection then escalate privileges using
From here on, we can unlock the container whenever we please and it is compatible with all other apps.
Conclusions
The approach described above uses cryptsetup, a widely deployed solution in the Linux world. It enables the user to store data securely and transparently. The container size limit (2GB) can be overcome by using ext2/3/4 instead of the default vfat on the “host” filesystem. Or use a dedicated partition for it.
While this article doesn’t dive deep into realizing a water tight system it illustrates one can take measures themselves to increase security. A pit fall of this solution is that one can forget to lock the container. A device without pattern or pin lock (I don’t trust it myself. Hell, at least it is something) cannot protect your data. It is also wise to turn off debugging mode otherwise an attacker can just hook up your phone on USB and then fire up adb which grants them root access to an unlocked container. Maybe I should write an article on securing Android
Several improvements can be made in the future:
- a GUI frontend to crypt.sh
- tight integration with the system: encrypt complete /sdcard and /data for instance
- use pin/pattern to unlock container
script: crypt.sh
# in kilobytes; vfat limits to 2G
SIZE=1900000
VOLNAME=crypt
CRYPTSETUP=/sd-ext/bin/cryptsetup
SETUP(){
dd if=/dev/zero of=/sdcard/${VOLNAME}.raw bs=1024 count=${SIZE}
mknod /dev/loop21 b 7 21
losetup /dev/loop21 /sdcard/${VOLNAME}.raw
${CRYPTSETUP} --cipher aes-cbc-essiv:md5 --key-size 256 luksFormat /dev/loop21
${CRYPTSETUP} luksOpen /dev/loop21 ${VOLNAME}
mkfs.ext2 /dev/mapper/${VOLNAME}
${CRYPTSETUP} luksClose /dev/mapper/${VOLNAME}
losetup -d /dev/loop21
mkdir /sdcard/${VOLNAME}
}
MOUNT(){
mknod /dev/loop21 b 7 21
losetup /dev/loop21 /sdcard/${VOLNAME}.raw
${CRYPTSETUP} luksOpen /dev/loop21 ${VOLNAME}
mount /dev/mapper/${VOLNAME} /sdcard/${VOLNAME}
}
UMOUNT(){
umount /sdcard/${VOLNAME}
${CRYPTSETUP} luksClose /dev/mapper/${VOLNAME}
losetup -d /dev/loop21
}
case $1 in
setup) SETUP ;;
umount) UMOUNT ;;
*) MOUNT ;;
esac
No related posts.