[guardian-dev] APK signing keys are vulnerable WAS: pgp, nsa, rsa

Natanael natanael.l at gmail.com
Mon Sep 23 14:10:15 EDT 2013


I can only see one option that is plausible - update the old app, signed
with the old key, to be able to export it's data. You can't install a new
app in the place of the old one and just keep data, Android will require
that you uninstall the old app before you install the new one if their
package names are identical but signing keys differ.

To improve security for the data transfer to some degree, we could use
Intents to let the new app request the data from the old app, and ideally
the old app would verify which key the new app is signed with, and prompt
the user for authorization. Then the user would only need to install the
new app, open it and select "Import from the old app", click OK, and then
uninstall the old app.
Den 23 sep 2013 19:47 skrev "Abel Luck" <abel at guardianproject.info>:

> Daniel McCarney:
> >> Wow, that is bad news indeed.  It would be awesome to have
> androidobservatory.org also display full info about the signing keys,
> like the algorithm used, the bitness, generation date, etc. so we can
> easily check which keys are vulnerable.
> >
> > Working on rolling that functionality out. I had to rewrite the app
> import
> > pipeline so that I could store that information. I have the data
> collected but
> > it isn't user facing yet. I can tell you that looking at the ~6,000
> unique
> > certificates in the observatory data about 75% are RSA 1024.
> >
> > As far as I'm aware it isn't possible to learn the key generation date
> from the
> > certificate data in the PKCS7 structure stored in the META-INF directory
> of an
> > APK.
> >
> >> I figure if the NSA can break 1024 bit RSA, its only a matter of time
> before China also has that capability.  China are experts at industrial
> espionage, and they certainly know how to make chips.  It is very
> conceivable that they could acquire the NSA's RSA cracking chip design and
> then build it domestically.  Then I imagine that China would also be
> willing to sell those chips to allies, or perhaps even the highest bidder.
> >
> > Yeah, the current NIST[1] advice on key sizes is very clear that 1024
> bit RSA
> > should be deprecated (though evidently NIST might not be an unbiased
> source of
> > information...).
> >
> >> We'll have to make sure our signing key is not 1024 bit, and if so,
> work on a migration plan.  The easiest way to start is to sign all new apps
> with a new key.
> >
> > The pubkey in the cert used for the core Guardian Properties (ChatSecure,
> > Obscuracam, etc) is definitely 1024 RSA. So is the pubkey in the cert
> used for
> > Orweb. It would definitely be a good idea to start talking about
> migration
> > plan, (and using a strong keysize in a new cert for all new properties)
> >
> > - Dan
> >
>
> Hm, this seems quite important. Is there any established docs on how to
> perform a key migration without data loss?
>
> Also, I think we should make a blog post advisory out of this.
>
> ~abel
>
> _______________________________________________
> Guardian-dev mailing list
>
> Post: Guardian-dev at lists.mayfirst.org
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>
> To Unsubscribe
>         Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>         Or visit:
> https://lists.mayfirst.org/mailman/options/guardian-dev/natanael.l%40gmail.com
>
> You are subscribed as: natanael.l at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20130923/3a6c0263/attachment-0001.html>


More information about the Guardian-dev mailing list