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

Hans-Christoph Steiner hans at guardianproject.info
Wed Sep 25 16:19:58 EDT 2013


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 at 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
> 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
> 
> 
> 
> _______________________________________________
> 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/hans%40guardianproject.info
> 
> You are subscribed as: hans at guardianproject.info
> 

-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 941 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20130925/8d3278aa/attachment.pgp>


More information about the Guardian-dev mailing list