----- Forwarded message from Hans-Christoph Steiner <hans@guardianproject.info> -----
Date: Wed, 25 Sep 2013 16:19:58 -0400
From: Hans-Christoph Steiner <hans@guardianproject.info>
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" <abel@guardianproject.info>:
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" <abel@guardianproject.info>:
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
Eugen Leitl