Grepular

Android Privacy Guard and Subkeys

Written 6 years ago by Mike Cardwell

UPDATE 2015-April-22: APG development ceased a long time ago. You should use OpenKeychain now instead. OpenKeychain does not lack the feature mentioned in this blog post. It has all the features APG had and more and is a lot more polished and pleasant to use.

Android Privacy Guard (APG) is an application which lets you use PGP on Android phones. The email client “K-9 Mail“ is the main application which uses it. APG lacks a feature that I’ve wanted since I initially installed it. I wanted to import only my subkeys, leaving my master key offline. Ie, I wanted to export my subkeys from GnuPG using “–export-secret-subkeys” and import the result into APG. I have now achieved this. I will explain what subkeys are, why you might want to do this, and then tell you how to go about it.

If you’re already using GnuPG, you may be using a subkey without even realising it. When you generate a new key pair using “gpg –keygen”, by default you end up with a master key responsible for signing and certifying keys, and also a single subkey responsible for encryption. Here is an example keypair I just created using “gpg –keygen”, and then viewed by running: “gpg –edit-key C80ED3A9”:

pub  2048R/*80ED3A9*  created: 2012-04-10  expires: never       usage: *SC*  
                     trust: ultimate      validity: ultimate
sub  2048R/*E9C41E58*  created: 2012-04-10  expires: never       usage: *E*   
[ultimate] (1). Test Name <test@example.com>

From the above, you can see that the master key has an ID of C80ED3A9, and the encryption subkey has an ID of E9C41E58. With the –edit-key command still running, I then typed “addkey” and selected “(4) RSA (sign only)”. This gave me an additional subkey dedicated to signing only:

pub  2048R/C80ED3A9  created: 2012-04-10  expires: never       usage: SC  
                     trust: ultimate      validity: ultimate
sub  2048R/E9C41E58  created: 2012-04-10  expires: never       usage: E   
sub  2048R/*C70D73F7*  created: 2012-04-10  expires: never       usage: *S*   
[ultimate] (1). Test Name <test@example.com>

The new subkey for signing has an ID of C70D73F7. If I sign something using this keyring, it will automatically be signed using the most recently created signing subkey. Likewise, if I encrypt something with it, it will automatically use the latest encryption subkey. This is completely transparent to the end user. All they need to know is the ID of the master key, and GnuPG handles selecting the appropriate subkey.

So… Why would I want these subkeys? Well, now I’ve created them, the only thing the master key is responsible for is signing other keys and generating revocation certificates. My regular operations of signing and decrypting email and files can be done using only the subkeys. So, why don’t I just delete the master key, leaving only the subkeys behind? Of course, you’ll want to back it up first, but I’m not going into details on how to do that here. The technique for deleting a master key is strange:

gpg --export-secret-subkeys > subkeys.gpg
gpg --delete-secret-key C80ED3A9
gpg --import subkeys.gpg

What we did here was export the subkeys, delete the entire keyring, and then re-import the subkeys. Here’s what it looks like when I do a “–list-secret-keys” now:

sec*#*  2048R/C80ED3A9 2012-04-10
uid                  Test Name <test@example.com>
ssb   2048R/E9C41E58 2012-04-10
ssb   2048R/C70D73F7 2012-04-10

The “#” symbol didn’t exist there before. It basically represents the fact that the master key is “empty”. If you try and run any operations that require the master key, they will now fail. But you can still sign and decrypt using the subkeys. If you want to do anything that requires the master key, you’ll need to re-import it from your backup temporarily. If you try and import the “subkeys.gpg” file we created into the standard installation of APG, it will fail. There are two bug reports for this, the first of which was issued a year ago:

https://code.google.com/p/android-privacy-guard/issues/detail?id=104

https://code.google.com/p/android-privacy-guard/issues/detail?id=124

Fortunately, APG is open-source. I forked the github repository and made a few small modifications to it so that it wouldn’t fail when the master key is empty. You can fetch the source:

git clone git://github.com/mikecardwell/android-privacy-guard.git

There are basic build instructions here. But if you don’t fancy building it yourself, you can download a signed apk from here. Note that it was signed by my own key rather than the key used for the existing package, so you’ll need to completely uninstall APG first before trying.

The original code checked in several places that it is possible to extract private key material. I simply removed these checks, and everything seemed to work. I’m sure there are negative implications to this, so I don’t expect the original author of the app to accept my changes. Hence why I’m directing people to the fork. Ideally, he’d make the changes himself to the main repository and application. If he does, I will update this blog post.

Looking to hire somebody like me? I'm open to offers of full time employment and small contract jobs. Check out my hiring page. You can follow this Blog using RSS or . To read more, visit my blog index.

Feeling generous?BitcoinMoneroZcashPaypal