----- Forwarded message from Hans-Christoph Steiner ----- Date: Wed, 25 Sep 2013 16:19:58 -0400 From: Hans-Christoph Steiner To: guardian-dev@lists.mayfirst.org Subject: Re: [guardian-dev] APK signing keys are vulnerable WAS: pgp, nsa, rsa Organization: The Guardian Project User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 Also, we should document how to generate a good signing key. Pd0x just recommended this in #guardianproject: keytool -genkey -v -keystore test.keystore -alias testkey -keyalg RSA -keysize 8192 -sigalg SHA256withRSA -dname "cn=Test,ou=Test,c=CA" -validity 10000' .hc On 09/23/2013 03:15 PM, Natanael wrote:

How are you planning on doing it? Will you let the old app notify the user about having to install a new app, maybe pointing to Google Play or offering a direct download? After verifying that the import worked, you can also offer to open the app details in Android for the old app so quick uninstallation is easy. Have you written down the details anywhere yet? I'd like to see how you're planning on doing it.

Den 23 sep 2013 20:44 skrev "Abel Luck" :

...

Yup, we just outlined this process in IRC :)

Anyone have a snippet of Java that lets an app check another app's signing key?

~abel

Natanael:

...

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

...

...

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

...

...

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

...

...

uninstall the old app. Den 23 sep 2013 19:47 skrev "Abel Luck" :

...

...

...

Wow, that is bad news indeed. It would be awesome to have androidobservatory.org also display full info about the signing keys,

Daniel McCarney: 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

...

...

...

...

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

of an 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

...

should be deprecated (though evidently NIST might not be an unbiased

bit RSA 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

new prompt then directory 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@lists.mayfirst.org List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev

To Unsubscribe Send email to: Guardian-dev-unsubscribe@lists.mayfirst.org Or visit:

https://lists.mayfirst.org/mailman/options/guardian-dev/natanael.l%40gmail.c...

...

You are subscribed as: natanael.l@gmail.com

_______________________________________________ Guardian-dev mailing list

Post: Guardian-dev@lists.mayfirst.org List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev

To Unsubscribe Send email to: Guardian-dev-unsubscribe@lists.mayfirst.org Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/hans%40guardianproje...

You are subscribed as: hans@guardianproject.info

-- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 _______________________________________________ Guardian-dev mailing list Post: Guardian-dev@lists.mayfirst.org List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To Unsubscribe Send email to: Guardian-dev-unsubscribe@lists.mayfirst.org Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/eugen%40leitl.org You are subscribed as: eugen@leitl.org ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5