» » Droidcedas : Using App Encryption Inwards Jelly Bean

Droidcedas : Using App Encryption Inwards Jelly Bean

Oleh
The latest Android version, 4.1 (Jelly Bean) was announced in conclusion calendar week at Google I/O with a bunch of novel features together with improvements. One of the to a greater extent than interesting features is app encryption, but in that location haven't been whatever details also the brusque announcement: 'From Jelly Bean together with forward, paid apps inward Google Play are encrypted amongst a device-specific fundamental earlier they are delivered together with stored on the device.'. The lack of details is of course of teaching giving ascent to guesses together with speculations, some people fifty-fifty fright that they volition conduct maintain to repurchase their paid apps when they learn a novel device. In this article nosotros volition aspect at how app encryption is implemented inward the OS,  show how yous tin install encrypted apps without going through Google Play, together with accept a peak at how Google Play delivers encrypted apps.

OS back upward for encrypted apps

The previous version of this article was based on Eclipse framework source packages together with binary organisation images, together with was missing a few pieces. As Jelly Bean source has at nowadays been opened upward sourced, the give-and-take below has been revised together with is now based on the AOSP code (4.1.1_r1). If yous are coming dorsum yous mightiness desire to re-read this post, focusing on the minute part.

Apps on Android tin last installed inward a few dissimilar ways:
  • via an application shop (e.g., the Google Play Store, aka Android Market)
  • directly on the telephone past times opening app files or e-mail attachments (if the 'Unknown sources' options is enabled)
  • from a calculator connected through USB past times using the adb install SDK command
The outset ii don't render whatever options or particular insight into the underlying implementation, so let's explore the tertiary one. Looking at the adb usage output, nosotros run across that the install command has gained a few novel options inward the latest SDK release:

adb install [-l] [-r] [-s] [--algo <algorithm name> --key <hex-encoded key>  --iv <hex-encoded iv>] <file>

The --algo, --key together with --iv parameters patently conduct maintain to do amongst encrypted apps, so earlier going into details lets outset essay to install an encrypted APK. Encrypting a file is quite slowly to do using the enc OpenSSL commands, ordinarily already installed on most Linux systems. We'll utilization AES inward CBC trend amongst a 128 fleck fundamental (a non rattling secure one, equally yous tin run across below), together with specify an initialization vector (IV) which is the same equally the fundamental to brand things simpler:

$ openssl enc -aes-128-cbc -K 000102030405060708090A0B0C0D0E0F  -iv 000102030405060708090A0B0C0D0E0F -in my-app.apk -out my-app-enc.apk

Let's banking concern check if Android likes our newly encrypted app past times trying to install it: 

$ adb install --algo 'AES/CBC/PKCS5Padding' --key 000102030405060708090A0B0C0D0E0F  --iv 000102030405060708090A0B0C0D0E0F my-app-enc.apk         pkg: /data/local/tmp/my-app-enc.apk Success

The 'Success' output seems promising, together with certain plenty the app's icon is inward the organisation tray together with it starts without errors. The actual apk file is copied inward /data/app equally usual, together with comparison its hash value amongst our encrypted APK reveals that it's inward fact a dissimilar file. The hash value is precisely the same equally that of the master copy (unencrytped) APK though, so nosotros tin conclude that the APK is beingness decrytped at install fourth dimension using the encryption parameters (algorithm, fundamental together with IV) nosotros conduct maintain provided. Let's aspect into how this is truly implemented. 

The adb install ascendance only calls the pm Android ascendance trace utility which lets us list, install together with delete packages (apps). The constituent responsible for installing apps on Android has traditionally been the PackageManagerService together with the pm is just a convenient frontend for it. Apps ordinarily access the bundle service through the facade degree PackageManager. Browsing through its   code together with checking for encryption related methods nosotros discover this: 

public abstract void installPackageWithVerification(Uri packageURI,         IPackageInstallObserver observer, int flags, String installerPackageName,         Uri verificationURI, ManifestDigest manifestDigest,         ContainerEncryptionParams encryptionParams);

The ContainerEncryptionParams degree looks particularly promising, so let's peek inside: 

public degree ContainerEncryptionParams implements Parcelable {     soul terminal String mEncryptionAlgorithm;     soul terminal IvParameterSpec mEncryptionSpec;     soul terminal SecretKey mEncryptionKey;     soul terminal String mMacAlgorithm;     soul terminal AlgorithmParameterSpec mMacSpec;     soul terminal SecretKey mMacKey;     soul terminal byte[] mMacTag;     soul terminal long mAuthenticatedDataStart;     soul terminal long mEncryptedDataStart; }

The adb install parameters nosotros used inward a higher house neatly agree to the outset iii fields of the class. In improver to that, the degree also stores MAC related parameters, so it's rubber to assume that Android tin at nowadays banking concern check the integrity of application binaries. Unfortunately, the pm ascendance doesn't conduct maintain whatever MAC-related parameters (it does actually, but for some argue those are disabled inward the electrical current build), so to essay out the MAC back upward nosotros postulate to telephone telephone the installPackageWithVerification method directly.

The method is hidden from SDK applications, so the exclusively way to telephone telephone it from an app is to utilization reflection. It turns out that most of its parameter classes (IPackageInstallObserver, ManifestDigest together with ContainerEncryptionParams) are also hidden, but that's exclusively a youngster snag. Android pre-loads framework classes, so fifty-fifty if yous app bundles a framework class, the organisation re-create volition ever last used at runtime. This agency that all nosotros conduct maintain to do to learn a handgrip for the installPackageWithVerification method is add together the required classes to the andorid.content.pm bundle inward our app. Once nosotros conduct maintain a method handle, nosotros just postulate to instantiate the ContainerEncryptionParams class, providing all the encryption together with MAC related parameters. One affair to greenback is that since our entire file is encrypted, together with the MAC is calculated over all of its contents (see below), nosotros specify 0 for both the encrypted together with authenticated information start, together with the file size equally the information halt (see sample code). To calculate the MAC value (tag) nosotros in 1 lawsuit once to a greater extent than utilization OpenSSL:

$ openssl dgst -hmac 'hmac_key_1' -sha1 -hex my-app-enc.apk HMAC-SHA1(my-app-enc.apk)= 0dc53c04d33658ce554ade37de8013b2cff0a6a5

Note that the dgst ascendance doesn't back upward specifying the HMAC fundamental using hexadecimal or Base64, so yous are express to ASCII characters. This may non last a expert stance for production use, so consider using a existent fundamental together with calculating the MAC inward another way (using JCE, etc.).

Our app is generally laid upward now, but installing apps requires the INSTALL_PACKAGES permission, which is defined amongst protection flat signatureOrSystem. Thus it is granted exclusively to apps signed amongst the organisation (ROM) key, or apps installed inward the /system partition. Building a Jelly Bean ROM is an interesting excercise, but for now, we'll only re-create our app to /system/app in company to learn the necessary permission to install packages (on the emulator or a rooted device). Once this is done, nosotros tin install an encrypted app via the PackageManager together with Android volition both decrypt the APK together with verify that the bundle hasn't been tampered amongst past times comparison the specified MAC tag amongst value calculated based on the actual file contents. You tin essay out that using the sample application past times slightly changing the encryption together with MAC parameters. This should effect inward an install error.



The android.content.pm bundle has some to a greater extent than classes of interest, such equally MacAuthenticatedInputStream together with ManifestDigest, but the actual APK encryption together with MAC verification is done past times the DefaultContainerService$ApkContainer, run of the DefaultContainerService (aka, 'Package Access Helper').

Forward locking

'Forward locking' popped upward around the fourth dimension ringtones, wallpalers together with other digital 'goods' started selling on mobile (feature) phones. The cite comes from the intention -- halt users from forwarding files they conduct maintain bought to their friends together with family. The primary digital content on Android were originally apps, together with equally paid apps gained popularity, sharing (and afterwards re-selling those) was becoming a problem. Application packages (APKs) conduct maintain been traditionally basis readable on Android, which made extracting apps from fifty-fifty a production device relatively easy. While world-readable app files mightiness audio similar a bad idea, it's rooted inward Android's opened upward together with extensible nature -- tertiary political party launchers, widget containers together with utility apps tin easily inspect APKs to extract icons, widget definitions available intents, etc. In an endeavor to lock downward paid apps without losing whatever of the OS flexibility, Android introduced forwards locking (aka, 'copy protection'). The stance was to separate app packages into ii parts -- a world-readable part, containing resources together with the manifest (in /data/app), together with a bundle readable exclusively past times the organisation user, containing executable code (in /data/app-private). The code bundle was protected past times file organisation permissions, together with patch this made it inaccessible to users on most consumer devices, 1 exclusively needed to gain root access to last able to extract it. This approach was speedily deprecated, together with online Android Licensing (LVL) was introduced equally a replacement. This, however, shifted app protection implementation from the OS to app developers, together with has had mixed results.

In Jelly Bean, the forwards locking implementation has been re-designed together with at nowadays offers the powerfulness to shop APKs inward an encrypted container that requires a device-specific fundamental to last mounted at runtime. Let's aspect into the implementation inward a fleck to a greater extent than detail.

Jelly Bean implementation

While encrypted app containers equally a forwards locking machinery are novel to JB, the encrypted container stance has been around since Froyo. At the fourth dimension (May 2010) most Android devices came amongst express internal storage together with a fairly large (a few GB) external storage, ordinarily inward the shape of a micro SD card. To brand file sharing easier, external storage was formatted using the FAT filesystem, which lacks file permissions. As a result, files on the SD carte du jour could last read together with written past times anyone (any app). To forestall users from only copying paid apps off the SD card, Froyo created an encrypted filesystem icon file together with stored the APK inward it when yous opted to motion the app to external storage. The icon was together with so mounted at runtime using Linux's device-mapper together with the organisation would charge the app files from the newly created mountain betoken (one per app). Building on this, JB makes the container EXT4, which allows for permissions. Influenza A virus subtype H5N1 typical forwards locked app's mountain betoken at nowadays looks similar this:

shell@android:/mnt/asec/org.mypackage-1 # ls -l ls -l drwxr-xr-x organisation   organisation            2012-07-16 15:07 lib drwx------ root     root              1970-01-01 09:00 lost+found -rw-r----- organisation   u0_a96    1319057 2012-07-16 15:07 pkg.apk -rw-r--r-- organisation   organisation     526091 2012-07-16 15:07 res.zip

Here the res.zip holds app resources together with is world-readable, patch the pkg.apk file which concur the total APK is exclusively readable past times the organisation together with the app's dedicated user (u0_a96). The actual app containers are stored inward /data/app-asec amongst filenames inward the shape pacakge.name-1.asec. ASEC container administration (creating/deleting together with mounting/unmounting) is implemented int the organisation book daemon (vold) together with framework services utter to it past times sending commands via a local socket. We tin utilization the vdc utility to deal forwards locked apps from the shell: 

# vdc asec listing vdc asec listing 111 0 com.mypackage-1 111 0 org.foopackage-1 200 0 asec functioning succeeded  # vdc asec unmount org.foopackage-1 200 0 asec functioning succeeded  # vdc asec mountain org.foopackage-1 000102030405060708090a0b0c0d0e0f G org.foopackage-1 000102030405060708090a0b0c0d0e0f  G                     200 0 asec functioning succeeded  # vdc asec path org.foopackage-1 vdc asec path org.foopackage-1 211 0 /mnt/asec/org.foopackage-1

All commands accept a namespace ID (based on the bundle cite inward practice) equally a parameter, together with for the mount ascendance yous postulate to specify the encryption fundamental together with the mountain point's possessor UID (1000 is system) equally well. That nearly covers how apps are stored together with used, what's left is to discover out the actual encryption algorithm together with the key. Both are unchanged from the master copy Froyo apps-to-SD implementation: Twofish amongst a 128-bit fundamental stored inward /data/misc/systemkeys:

shell@android:/data/misc/systemkeys # ls ls AppsOnSD.sks shell@android:/data/misc/systemkeys # od -t x1 AppsOnSD.sks od -t x1 AppsOnSD.sks 0000000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 0000020

Forward locking an application is triggered past times specifying the -l selection of the pm install ascendance or specifying the INSTALL_FORWARD_LOCK flag to PackageManager's installPackage* methods (see sample app).

Encrypted apps together with Google Play

All of this is quite interesting, but equally nosotros conduct maintain seen, installing apps, encrypted or otherwise, requires organisation permissions, so it tin exclusively last used past times custom carrier Android firmware together with likely the side past times side version of your friendly CyanogenMod ROM. Currently the exclusively app that takes payoff of the novel encrypted apps together with forwards locking infrastructure is the Play Store (who comes upward amongst those names, really?) Android client. Describing precisely how the Google Play customer industrial plant would require detailed cognition of the underlying protocol (which is ever a moving target), but a casual aspect at the newest Android customer does divulge a few useful pieces of information. Google Play servers ship quite a fleck of metadata nearly the app yous are nearly to download together with install, such equally download URL, APK file size, version code together with refund window. New amidst those are the EncryptionParams which aspect rattling similar to the ContainerEncryptionParams shown above:

class AndroidAppDelivery$EncryptionParams {   soul int cachedSize;   soul String encryptionKey;   soul String hmacKey;   soul int version; }

The encryption algorithm together with the HMAC algorithm are ever laid to 'AES/CBC/PKCS5Padding' together with 'HMACSHA1', respectively. The IV together with the MAC tag are bundled amongst the encrypted APK inward a unmarried blob. Once all parameters are read together with verified, they are essentially converted to a ContainerEncryptionParams instance, together with the app is installed using the familiar PackageManager.installPackageWithVerification() method. As mightiness last expected, the INSTALL_FORWARD_LOCK flag is laid when installing a paid app. The OS takes it from here, together with the procedure is the same equally described inward the previous section: gratuitous apps are decrypted together with the APKs halt upward inward /data/app, patch an encrypted container inward /data/app-asec is created together with mounted nether /mnt/asec/package.name for paid apps.

So what does all this hateful inward practice? Google Play tin at nowadays claim that paid apps are ever transferred together with stored inward encrypted form, together with so tin your ain app distribution channel if yous create upward one's heed to implement it using the app encryption facilities Jelly Bean provides. The apps conduct maintain to last made available to the OS at some betoken though, so if yous conduct maintain root access to a running Android device, extracting a forward-locked APK or the container encryption fundamental is soundless possible, but that is truthful for all software-based solutions.

Update: patch forwards locking is making it harder to re-create paid apps, it seems its integration amongst other services soundless has some issues. As reported past times multiple developers together with users here, it currently breaks apps that register their ain occupation organisation human relationship managing director implementation, equally good equally most paid widgets. This is due to some services beingness initialized earlier /mnt/asec is mounted, together with therefore non beingness able to access it. Influenza A virus subtype H5N1 laid upward is said to last available (no Gerrit link though), together with should last released inward a Jelly Bean maintenance release.

Update 2: It seems that the latest version of the Google Play client, 3.7.15, installs paid apps amongst widgets together with perchance ones that deal accounts inward /data/app equally a (temporary?) workaround. The downloaded APK is soundless encrypted for transfer. For example: 

shell@android:/data/app # ls -l|grep -i beautiful ls -l|grep -i beautiful -rw-r--r-- organisation   organisation    6046274 2012-08-06 10:45 com.levelup.beautifulwidgets-1.apk

That's nearly it for now. Hopefully, to a greater extent than detailed information both nearly the app encryption OS implementation together with pattern together with its usage past times Google's Play Store volition last available from official sources soon. Until then, learn the sample project, burn downward upward OpenSSL together with give it a try.
0 Komentar untuk "Droidcedas : Using App Encryption Inwards Jelly Bean"

Back To Top