3 ms·
Does anyone have a recommendation for what best practice for Android app signing key maintenance is (or maybe multiple people strongly suggesting entirely oppos
by saurik 7y ago
Does anyone have a recommendation for what best practice for Android app signing key maintenance is (or maybe multiple people strongly suggesting entirely opposite ideas ;P), under an assumption that one absolutely intends to be distributing their app via numerous sources (not just the Play Store)? Our app (which hasn't launched yet) is security critical for the user (it is a VPN client, and so can see all of the user's traffic, as well as a cryptocurrency application, and so has access to some amount--not likely a large amount for various reasons: this isn't really a wallet--of money), and so with the appeal of "immediately steal money from users" we expect it/us to be targeted even with lower install counts (so this isn't a pipedream with a reality check of "we are never going to get popular anyway").
We are totally willing to do "weird" things with hardware signing keys in the name of security... it just isn't really clear what the correct thing to do is :(. Should we be using Google Play App Signing for the Play Store, even if we can't do that for other distribution mechanisms? As I kind of remember unrelated stores being able to manage and upgrade apps (particularly free ones) from different stores, as they just get a list of installed apps from the OS, it would seem problematic to use a _lot_ of different keys (such as one per store)? I will again note that, due to our constraint of being pretty sure we will have off-App Store distribution (some of our key markets don't use the Play Store much), we need to solve the key security problem for non-Play Store distribution "anyway", and so can't just fall back on "don't do local signing".
Meanwhile, I didn't even know yet about the Android 9 key rotation feature mentioned in this article, which I could see maybe having major changes on best practices here, though maybe only "going forward" (given how few users have upgraded to Android 9 so far, and now that I think about it probably won't for years to come...). In a world where you can effectively never change your key, it seems really important to have your act together on "day 1" to get stuff right (though I also am not even sure what is reasonably possible, given how I think it all fundamentally relies on a single key? so we can't do some kind of multi-sig? I also don't know if we can do sub-certificates with short signing duration with a root certificate backed by a vaulted key, as people often do for SSL?)
- tomatocracy 7y agoWhatever you do, if you are high value then you should consider the risk that your source repository could be compromised too. Using separate hardware signing keys for git/whatever is something you should therefore also strongly consider I think. Reproducible builds can also help you to mitigate this risk - so you then can cross check that the source is properly signed and produces the right binary before signing the binary. If you are publishing source code then your customers can also double check this as a second vector, should they want to.
- munchbunny 7y agoIf you have to do local signing at some point, then an offline HSM protected by a quorum of unlock keys would be one way to make sure your key won't end up somewhere you didn't intend and is resistant to single internal compromised employees. Crack open the safe, take out the HSM, turn it on, sign the build, and then put the HSM back into its safe. If you want to go the extra mile, some of the HSM's have ways to generate the same key onto two HSM's, and you can put the second one in a bank vault for backup.