Signing Key on Guardian Project

Building a Signing Server

Mon, 18 Dec 2017 05:43:34 -0400

The Android APK signing model sets the expectation that the signing key will be the same for the entire lifetime of the app. That can be seen in the recommended lifetype of an Android signing key: 20+ years. On top of that, it is difficult to migrate an app to a new key. Since the signing key is an essential part to preventing APKs from impersonating another, Android signing keys must be kept safe for the entire life of the app.

The F-Droid repo signing keys follow a very similar model: the signing key is the essential way to safely identify an F-Droid repo. So the same considerations apply to F-Droid repo signing keys as to APK signing keys. This also provides some really useful benefits. Since the integrity of the repo index file and the APKs are guaranteed by the repo signature, the files can be delivered via whatever method is most convenient, and their integrity will be automatically verified by the F-Droid client app, the f-droid.org deploy process, and Repomaker.

This means the security burden is shifted from the online, public webserver to a private signing machine. Just keeping that machine out of the public eye goes a long way towards improving security. There are a number of additional measures that can be taken to further improve the security of the signing process. Here are some approaches, starting with the easiest and least security, and going on to more secure setups that require more work to setup and run. Signing is not an resource intensive process, so any machine will work, even a 10 year old, basic laptop. We recommend using a minimal Debian install, and rebuilding the machine from scratch.

Automated Signing Server with with HSM

For a fully automated signing setup, the machine running the signing needs to be online and running. Ideally this machine would have no remote access, at the very least remote access should be very carefully controlled and monitored. A laptop makes it easy to work with even when remote access is disabled, since it provides a built-in keyboard and monitor. If remote access is required, then any basic PC will work fine. Using a Hardware Security Module (HSM) to store the keys prevents them from being stolen if the server is broken into. An attacker could only run the signing process on that server.

Ideally, this machine would only be accessible via Tor. That hides the physical location of the server, and hides the traffic from network. This makes it much harder attackers to find the actual machine to attack.

For the HSM, we recommend using Nitrokey hardware, since they are free software/hardware, and provide a wide range of options. Use a separate machine to put the signing keys on HSM. A good HSM will keep an audit trail of how many signatures have been made, so that information could be used to create an automatic auditing process to raise alarms if too many signatures have been made. That could mean that this server was breached and used to sign unauthorized packages.

Other possibility it to use a setup like Fedora‘s Sigul that involves three machines.

Basic laptop dedicated to signing

Start with a laptop that can be wiped clean and rebuilt from scratch. What is most important is that only the essential software is installed on it, and nothing else. Do not include any browser at all, for example, since that is the most common vector of attack. No remote access setup (e.g. SSH or VNC) should be installed or configured. To sign apps and repos, someone would take out this laptop, connect it to the network, and run the signing process. The signed results can then be published via the network connection. When the signing is complete, the machine can be turned off and disconnected and kept in a safe place.

This could be made quite automatic with some custom scripts. The person running the process would only need to take out the machine, connect it, turn it on, wait until the process completes, then put it all away again.

Fully offline signing laptop with USB thumb drives

_update: apt-offline has a security bug so it was removed from Debian/buster. It is no longer recommended! Instead, use the Debian “apt offline” setup._

This process is based on the same basic, stripped down laptop as the previous example. But this time, the networking should be entirely disabled before the install process. For example, it is easy in many laptops to physically remove the WiFi card. Therefore, it makes sense to use a laptop that does not include an ethernet jack, which are usually not possible to remove. Otherwise, blacklisting all kernel modules related to neworking can suffice. Since this machine is fully offline, the extra work of using an HSM is not as important, but it can’t hurt to include it.

Download the full “CD” or “DVD” image of Debian to run the install. Be sure to verify the GPG signatures and the SHA-256 hashes. One essential utility is apt-offline, which automates the process of downloading Debian packages, verifying their signatures, and copying them over to an offline machine.

To be extra careful, all of the software used should be verified. Chromebooks are nice, cheap laptops that run Linux natively. They also use Coreboot for the BIOS.

Buy a computer off the shelf with cash, avoid having it shipped, especially across borders

Buy a Debian-supported Chromebook with removeable WiFi hardware, and needs no binary blobs

Install a reproducibly built coreboot binary

Install from a reproducibly built Debian image, wiping out Chrome OS entirely

The Physical Environment

The last thing to consider is the physical location where signatures happen, and where essential equipment is stored. The signing environment must be physically secure. Otherwise, there is no way to prevent laptops or HSMs from being lost or used to sign inappropriate content. For the offline machines, keeping them in a locked room is a good start. For an online machine, forcing all network traffic and remote access over Tor hides the physical location of the machine from network observers.

For high risk signing keys, using multiple layers of defense is important:

Restricted physical access to HSMs or smart cards
Security cameras
Onsite security guards
Visitor logging
A tools-resistant server safe for online code-signing servers

The signing server should be physically separate from the rest of the infrastructure. And the logs, machine, and network should be periodically audited.

Difficult decisions

Ideally all of these practices would be put into place, but each of these security measures comes at a cost of difficulty, expense, and complexity. They can also delay the process of getting regular updates out. So there are risks of implementing too strict security policies, much like the risks of not implementing enough.

How to Migrate Your Android App’s Signing Key

Tue, 29 Dec 2015 12:03:54 -0400

It is time to update to a stronger signing key for your Android app! The old default RSA 1024-bit key is weak and officially deprecated.

What?

The Android OS requires that every application installed be signed by a digital key. The purpose behind this signature is to identify the author of the application, allow this author and this author alone to make updates to the app, as well as provide a mechanism to establish inter-application trust. The Android security model defines an app by two things: the package name (aka packageName, ApplicationID, package) and the signing key. If either of those are different, then Android considers it a different app. When the package name and signing key of one APK match an installed app, then the APK is considered an update and Android will replace the installed app with the APK. If the APK is signed by a different key, then Android will prevent installing and updating.

First thing is to see what the current signing key is. Check any app’s signing key using our free utility app Checkey:

Lookout needs to generate a new key!

The official Android docs have tons of useful information about what the signing keys are good for, how to generate them, and how to use them. Unfortunately, it doesn’t provide any instructions for migrating, and for many years, 1024-bit RSA was the default. But first, why would you want or need to migrate?

Why?

Depending on when you created your signing key, you might have a particularly weak key. The primary danger of a weak key is that an adversary could break your key in order to generate fake APK signatures. Then those malicious APKs can be installed as updates to your app. There are other nefarious purposes depending on how you use the signing key in your apps. Or if you are unfortunate enough to have suffered a loss of your private key material, then it is definitely time for a new signing key.

According to our friends at the Android Observatory, over 64% of Android apps in their data store use 1024-bit signing keys (RSA or DSA).

There are several good reasons to migrate off of 1024-bit RSA keys, even though there is no public proof of a 1024 prime factorization required to generate any 1024-bit key at will. The evidence has been mounting for a decade.

NIST’s official guidelines (PDF, page 64 and 67) deprecated 1024-bit RSA keys at the end of 2013. This deprecation by NIST isn’t an indication that 1024-bit RSA is compromised, instead it is a preemptive move to stay ahead of attacks. Confidence in NIST might be shaken in light of recent revelations, but in this case increasing the RSA key size is unlikely to trigger any secret NSA backdoors. If anything, the deprecation year could have been extended slightly to allow the NSA a window where they had the capacity to factor 1024-bit keys and everyone was still using them. So, it’s time to move on.

For an example, a decade ago the cost of building special purpose hardware capable of breaking a single 1024-bit RSA key in one year was estimated at $10 million (Adi Shamir, Eran Tromer, On the cost of factoring RSA-1024, 2003). Presumably the techniques have improved by orders of magnatude, and the hardware value depreciated. It is conceivable the cost has fallen enough to be affordable not only by nation-state actors, but by large criminal enterprises too.

For a comprehensive talk on the state of the art (as of December 2012) when it comes to breaking 1024-bit RSA, check out the 29C3 talk FactHacks: RSA factorization in the real world with the cryptographers Daniel J. Bernstein, Nadia Heninger, and Tanja Lange (watch recording)

How?

Migrating to a strong key for an Android app is, unfortunately, not so simple. If you are publishing a new app to the app store, then simply generate a new strong signing key and you’re done. Congratulations! However, there exists no easy way to update your signing key for an existing application, because an installed application can only take updates from an APK signed with the same key.

Here we outline a basic method with which you can use to fake an update to your signing key. This is not as user friendly as we would like. Some of the hard facts of performing this process is that for most app stores including Google Play, you will lose ratings and reviews since the app will show up with a new package name, and the app store will treat it like an entirely new app. Also, the user will have to manually uninstall the original app once they finish the procedure. Here is a rough outline of the process:

generate the new signing key, RSA 4096
Update the first app, App1, with a mechanism for exporting private data, using TrustedIntents with a signature pin of the new key, RSA 4096, which Checkey will generate for you
Create a new version of the app with a different package name, App2
sign App2 with new key, RSA 4096
Add method to App2 for receiving user data from App1, including a signature pin of the old signing key, RSA 1024, for use with TrustedIntents
Publish App2 to the app stores
From App1, prompt user to install App2
runs and imports data from App1
App2 prompts user to uninstall App1

For F-Droid, there will be some easier tools for handling this. The F-Droid system is already used to multiple signing keys per app since F-Droid uses its own signing key for many of the apps it releases, and that F-Droid signing key is different from the signing key that the original developer used in their Google Play uploads. F-Droid will likely be able to support APKs with the same package name but with multiple signing keys.

A Note on Compatibility

There is security vs compatibility trade off a few might be interested in. Pre-4.3, Android did not support any signature algorithms except SHA1. With Android >= 4.3, SHA256 support was fixed, and SHA384, SHA512, and ECDSA were added (source). There are still android 2.3.3 (android-10) devices being sold, so anyone interested in backwards compatibility will have to heed this.

Also, the larger the keysize and hashsize used, the longer it takes to install and update the application. So extremely large values might be unsuitable for slower hardware. The following probably doesn’t buy you a tremendous amount of additional security but cranks the paranoia to 11. It does so at the cost of compatibility and performance.
 Gen with: keytool -genkey -v -keystore test.keystore -alias testkey -keyalg RSA -keysize 4096 -sigalg SHA512withRSA -dname "cn=Test,ou=Test,c=CA" -validity 10000 Sign with: jarsigner -verbose -sigalg SHA512withRSA -digestalg SHA512 -keystore test.keystore test.apk testkey 

We have some scripts that we use to generate keys in our smartcard-apk-signing repo. It is also possible to generate an Android signing key using openssl or other libraries. It is often wise to use different software than standard for doing things like generating keys. Since the Java keytool approach that is the standard, recommended method for Android, that makes it a target for adversaries that are interested in breaking keys. If a key was generated using openssl or GNU TLS instead, for example, then that key would not be affected if keytool had a bug like Debian’s CVE-2008-0166.