Task #1982

investigate OTR key as signing key for jars

Added by hans over 4 years ago. Updated almost 4 years ago.

Status:ClosedStart date:10/02/2013
Priority:NormalDue date:
Assignee:hans% Done:

0%

Category:-
Target version:0.2 - ChatSecure/Bluetooth
Component:

Description

Bazaar will need to sign the index of the list of APKs. When OTR connections are already being used, might as well re-use the key to sign the APK.


Related issues

Related to Bazaar - Task #1981: investigate self-signed HTTPS key as signing key for jars Closed 10/02/2013

History

#1 Updated by hans over 4 years ago

Should ChatSecure have an Intent for verifying data signed by OTR private keys? Or should F-Droid be able to read ChatSecure's secret key material in order to use it for its own signing? Most likely, F-Droid will need to use the raw key material itself since ChatSecure won't be able to support every kind of signing possibility under the sun.

Another option would be to have FDroid always generate its own internal key for use with zipsigner and the HTTPS web server. Then once it signs the index.jar, it would send it to ChatSecure or GPG to be signed with a gpg-style --detach-sign signature file. This would make the validation more complex, since there would be two types of signatures to validate (zipsigner and gpg-style).

#2 Updated by hans over 4 years ago

Thinking about this a bit more, it seems that there are other uses for a secret key sharing Intent or permission. For example, since GPG has a good track record for not having random-related exploits in its key generation code (I believe it only uses random data, not a PRNG like Android/Java), ChatSecure could call on GPG to generate the DSA key for OTR. So F-Droid could request the key data from GPG as well. The question is whether ChatSecure should also be able to share its secret key material.

As for making this secure, there are a number of things we can do:

  • APK-pinning based on shared signing key
  • APK-pinning based on package name
  • checksum TOFU on first request for key material
  • all of the above

#4 Updated by n8fr8 over 4 years ago

  • Target version set to 0.1 - "Kerplapp"

#5 Updated by hans about 4 years ago

  • Target version changed from 0.1 - "Kerplapp" to 0.2 - ChatSecure/Bluetooth

#6 Updated by hans almost 4 years ago

  • Status changed from New to Closed

I think we are good going with the combined repo and HTTPS private key. Figuring out how to securely use the OTR key for signing seems more work than its currently worth.

Also available in: Atom PDF