Use a secure channel to distribute binaries

[fschwebel]

The source code is currently on GitHub and the binaries as attachment on XDA or on the official website http://repo.xposed.info/module/de.robv.android.xposed.installer. None of those channels provide secure transmissions (e.g. HTTPS) for downloading binaries. Xposed, when installed, has every possible rights on the device, and we have seen in the past that it does interest major players that have the ability to easily perform MitM attacks on unencrypted communications. It would be easy to make repo.xposed.info use SSL (please have a look at https://letsencrypt.org/ for a no-cost solution), and to make it the central distribution point. The XDA threads could then link to the central repository, and it would also secure the distribution of all modules (which are also all very security sensitive). If you are worried about the load on the server due to links on XDA you could consider attaching the files in GitHub releases and using GitHub as CDN. In parallel, publishing the SHA-256 sums of the files would be a nice-to-have.

[liudongmiao]

1. xposed installer are distributed via xda forum
2. github offer https
3. all the apk are signed using rovo89's key
4. all the module are md5 too, and many xposed modules don't spread via xposed repo.

[fschwebel]

Thanks Liu but what is your point on each of those?

1. XDA uses a CDN that download on links such as http://dl-1.va.us.xda-developers.com/3/5/4/3/4/1/9/xposed-v78-sdk23-arm64.zip?key=acomplextoken&ts=1447911151. No security here.
2. GitHub does indeed, but the binaries cannot be downloaded here
3. The APK are signed, but this signature is only used for updates consistency checks, and when installed from the Google Play; when downloaded on the internet, there is no signature verification, as anyone can make a certificate with with Rovo89's name on it, it just won't be his. In the end, Android will noneless install the APK. (cf. https://developer.android.com/tools/publishing/app-signing.html)
4. The MD5 published in the Xposed repository are distributed on the same site, also without SSL, so that is to be considered as a CRC, not a proof of integrity

I am just saying, if you are asking for root permissions, please distribute your application carefully. For the module distribution, well, that is outside of the scope, even if the installer could mention a warning when applicable saying it is unable to download it securely.

[dkisselev]

Last I checked, Android would complain at you and make you uninstall a version with the wrong key before installing the new APK.

But that definitely doesn't help the fact that the zip's may not be signed (and are definitely not signature checked)

[dillbyrne]

+1 for this

[foresto]

@liudongmiao: Actually, the xposed-v80-sdk22-arm.zip I just downloaded seems to be signed by a generic key, not rovo89's key. I've never used jarsigner before, but it reports EMAILADDRESS=android@android.com, CN=Android.

In any case, I agree with @fschwebel in that an easy way for a non-developer to validate xposed downloads would be very helpful. We're placing an awful lot of trust in them, after all.

[rovo89]

Question to you guys: I could sign further things with the same key as the Xposed Installer (which has been downloaded millions of times since 2012, so it should be sufficiently clear that the signature is genuine). However, I'm wondering how people would actually easily be able to verify it, because just seeing my nickname in the certificate doesn't say anything. If nobody is able to verify that the signature is 100% the same as the legitimate one, its a false impression of security.

Also: I could successfully extract the PKCS7 signature from the APK and from that the X.509 public key. I obviously have the private key as well. Any chance I could use that to sign any files/text (e.g. GPG), while still making it rather easy to confirm the signature? Could I maybe even use this to create new key pairs for various purposes (ZIP signing, signed hashes of files I release) and sign them with the known key?

[dillbyrne]

Personally A GPG signature would suit me fine. You could list your key fingerprint in the readme and then list the signature files on github. This would be less effort than extracting the sigs from the apk and you can also use the same GPG key to sign other related releases or modules providing a common base of trust.

The people who would most likely be verifying the apk would be familiar with GPG. it is available on all desktop platforms and APG could also be used on the device.

Thanks for taking this issue into consideration and for your work.

[dkisselev]

From what I'm gathering from the docs, if signature verification is turned on in recovery (which it isn't for most people, but we'll assume that it is for people in this thread because if they have it disabled this whole thread is moot as you mentioned), it will check that all zips are signed with a key that appears in /system/etc/security/otacerts.zip

https://source.android.com/devices/tech/ota/sign_builds.html#signatures-sideloading

This is talking about Android OS release builds but I'm assuming the xposed zip is similar.

So basically users would have to get the xposed public key into their otacerts.zip, either through a new function of xposed installer (use root to add the key) or by manually verifying the validity of an xposed zip, installing it, and the zip will add itself to the accepted keys; then make sure to keep signature verification on so that recovery actually fails on a bad update. I imagine OS updates (nightlies or otherwise) would wipe out otacerts, so it would need to be re-added.

I agree that GPG would probably be the easiest solution though.

[rovo89]

This is talking about Android OS release builds but I'm assuming the xposed zip is similar.

The Xposed ZIPs can only be flashed using custom recoveries like TWRP. As far as I know, these just check that the file is signed at all - no matter with which certificate. So it would be up to the user to verify the ZIP. I also wouldn't want to mess with the OTA certs installed on the device.

Regarding the GPG: The question is really how to prove that the fingerprint I post somewhere is legitimate, i.e. nobody hacked my GitHub account and posted their fingerprint. Any chance I case use the PKCS12 key to "sign" the message where I post the fingerprint? Getting the fingerprint from the APK certificate for verification seems to be quite easy: keytool -printcert -file CERT.RSA

[foresto]

It seems to me that we need three things here:

1. A tool for revealing what key was used to sign an apk file. The only such tool I've found that looks trustworthy (meaning well-known, open source, and run locally) is jarsigner.
2. A way to verify whether a key (the one found by the first tool) belongs to the set of keys that a user trusts. Since trusted keyring tools vary between platforms, perhaps it would make sense to direct users to Java's keytool/keystore, and let people using other keyrings figure out their tools' equivalent steps?

Since jarsigner, keytool, and most other key-management programs have intimidating command line syntax, it might be worth publishing a simple wrapper script to make using them easy, essentially consolidating 1 and 2. This looks like a pretty good start: https://github.com/johnnylambada/robospanner/blob/master/apk/apk-validate

(A similar script could wrap platform-specific keyring tools.)

1. A strong assurance that a published key hasn't been faked (or intercepted and replaced) before a user adds it to his keyring. That's probably best done with a web of trust: having your key signed by several well-known people's well-known keys. A certificate authority is sometimes used instead, mainly for convenience, though CAs are arguably less secure. Just publishing your key (and your apk file hashes) on a bunch of different https-protected websites might be a worthwhile start; it wouldn't be the strongest of assurances, but at least for people who trust https, it would guard against a single compromised site or a man-in-the-middle attack.

This short article is worth reading: https://tails.boum.org/doc/get/trusting_tails_signing_key/

[rovo89]

This short article is worth reading: https://tails.boum.org/doc/get/trusting_tails_signing_key/

Seems to be down...

As I realized that extracting the key from the APK and using it to verify signatures on other files/texts is too complicated, here's another idea. I could create a ZIP file with whatever information I want to prove as legitimate (e.g. a text file containing the GPG fingerprint). Then I could sign this ZIP file with the same keystore that I use for the APK.

Advantages:

• jarsigner can be used to verify that the ZIP file hasn't been tampered with (same for the APK)
• The META-INF/CERT.RSA must be identical for both the APK and the ZIP and could be compared either byte-by-byte, via a hash on the extracted files or with keytool: http://android.stackexchange.com/questions/9312/how-can-i-verify-the-authenticity-of-an-apk-file-i-downloaded
• The information signed in this way can be used as a start point for further verification.
• It's basically an additional way to say: Trust this GPG fingerprint, it's really from the person who has posted Xposed Installer APKs all these years, no trust on other people is needed.
• It can be used in addition to other ways that confirm that the GPG fingerprint is genuine.
• Confirm this once, remember the fingerprint and you'll be able to check future releases easily.
• In the ZIP, I could also include further things like the public key in a more easily consumable format, instructions for verification or further data that might be helpful.

What do you think?

In addition to that, I'm wondering whether it makes sense to use this to sign a master key that I keep offline and just use to sign subkeys. Then I could use one subkey for release file signing, maybe an additional one for signing Git commits, ... i.e. things were I need to keep the key in remote places. Does that make sense?

[foresto]

I could create a ZIP file with whatever information I want to prove as legitimate (e.g. a text file containing the GPG fingerprint). Then I could sign this ZIP file with the same keystore that I use for the APK.

That might be a little easier than finding old Xposed releases and extracting their signing key's fingerprint, but it doesn't solve the trust problem: Regardless of whether a newcomer gets a key from a downloaded old version or a downloaded zip file, how can he be confident that what he downloaded is the same key that was used historically? After all, a compromised download site or man-in-the-middle offering fake/malicious new versions can just easily offer fake/malicious old versions and zip files.

no trust on other people is needed.

Involving multiple third parties is actually a great strength. Even if you don't trust them individually, just knowing that they all agree on which signature or file is the official one protects pretty well against a single point of failure (e.g. a compromised website or man-in-the-middle). Better still, if a file is signed with multiple keys and you trust some of them, all the strengths of the Web of Trust apply, and you have an even stronger assurance that all is well.

This short article is worth reading: https://tails.boum.org/doc/get/trusting_tails_signing_key/

Seems to be down...

Odd. It worked when I sent it, when your reply hit my inbox, and still does now. Maybe there's a routing or DNS problem between you and the server?

The Perspectives Project website has a short discussion that's also worth reading. It's an example of detecting faked content by avoiding a single point of trust failure: Multiple third parties publish what key they see on a website at any given time, and what key they saw historically. By comparing these reports to one another, any individual can detect a website or key compromise. http://perspectives-project.org/

[rovo89]

Involving multiple third parties is actually a great strength.

Sure. Nevertheless, isn't it a false sense of security to rely on how many people trust a certain key? Couldn't someone easily create 10,000 fake accounts which say that their fake key is trustworthy for Xposed zips? From my point of view, this is very important:

if a file is signed with multiple keys and you trust some of them

This requires that I actually trust some of them - but how could I do that? You always need one starting point for the chain of trust. If for example Chainfire signed my key, you would probably say "ok, I know that Chainfire is trustworthy, so rovo89's key is the legitimate one". But how would you know whether that Chainfire is the real one or just a fake? You probably never met him, so you would need someone else who signed his key, and so on.

On the internet, it's pretty hard to prove that you're legitimate. That's why I think there should be multiple ways to verify the key:

1. Let multiple people sign it. Could be hacked by fake accounts.
2. Post the fingerprint to several websites with HTTPS. Could be hacked by compromising the webserver.
3. Compare to older releases. Could be hacked by fake downloads, but if you already downloaded Xposed a long time ago, the chance for this decrease. As you said, it doesn't apply to newcomers.

Any thoughts about different keys for different purposes, which are all signed by a master key?

[foresto]

On Wed, 02 Mar 2016 01:02:57 -0800, rovo89 wrote:

Involving multiple third parties is actually a great strength.

isn't it a false sense of security to rely on how many people trust a certain key?

Yes, but that's not what I meant. To establish the validity of a file in the first place, merely seeing lots of random signatures on it clearly isn't enough; I would want at least one signature from someone whom I have reason to trust. In the absence of someone I know personally, I would look for signatures from a few people well-known in trusted communities, with track records of competence and honesty, and incentive to preserve their good reputations. For example, the Tails project has their signing key signed by several high-profile Debian developers. (This was explained on the page I linked earlier; I wish you were able to reach it.)

More signatures wouldn't be substitutes for trustworthy signatures, but they would expand the pool of people amongst whom I might find someone I trust. Every time I find another one, my confidence grows, and the system becomes more resistant to tampering.

Couldn't someone easily create 10,000 fake accounts which say that their fake key is trustworthy for Xposed zips?

Sure... and all 10,000 of those signatures would be unknown strangers to me, so I would simply ignore them all. Meanwhile, if a few of the signatures were from people whose online personas were well-known and generally trusted, then someone faking your key or tampering with a file you signed would require compromising multiple well-known people. A compromised download (man-in-the-middle) or hacked website would then be very easy to detect.

On the internet, it's pretty hard to prove that you're legitimate. That's why I think there should be multiple ways to verify the key:

1. Let multiple people sign it. Could be hacked by fake accounts.
2. Post the fingerprint to several websites with HTTPS. Could be hacked by compromising the webserver.
3. Compare to older releases. Could be hacked by fake downloads, but if you already downloaded Xposed a long time ago, the chance for this decrease. As you said, it doesn't apply to newcomers.

Yes, I agree. I didn't mean to discourage you from building upon the trust already established in the signing key you've used for years. I simply wanted to recognize that it's not enough by itself. (That trust only works for someone who has been archiving your releases all this time and has some way to prove that his downloads have never been compromised, either in transit or on disk. Everyone else needs another approach.) If you're planning to implement all three approaches, I'm no longer worried. :)

Any thoughts about different keys for different purposes, which are all signed by a master key?

I think it's a good idea. It might be a minor hassle to manage multiple keys, but it would also allow you to conveniently sign things from wherever you happen to be, with less risk: In the event of a signing key compromise, you wouldn't have to repeat the chore of getting multiple third parties to sign a new master key.

[rovo89]

OK, after some hours of digging into GPG-related documents, I was finally able to generate a new key (7235F333, sign-only) and a subkey (852109AA, sign-only), transfer only the secret of the subkey and import it on another server. gnu -K shows sec#, so I think the secret of the master key is really not available on that server. Then I could sign a file using gpg -ab xposed-v80-sdk23-arm.zip. Here's the result:

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCAAGBQJW5A6WAAoJEIZbcU6FIQmqF0IQANzD1dB9wfbzGQy4sbc1p4hX
bvlCr0gLsZG/FZ/UcIjD8zRkRnGVyZqYgpYcqLWg0OVYNOtMxG9JetmtROxpPyda
dGVIUSIfzI8ZoNuodMloK0enkuHGvSUmZtxbWp3vC0A+ZhPW37PAFAQYQ9v630J8
iR9gOgTQ924o9REY7n/TtheQhOvPKzJFKtHAkartaJz+HN1b1EH4MLGqzewgpE0P
37nTdjxSPCei4Pei5bWywXxjZjtO8bIyWIFZOsy9k/Jbtcy8MClV17FODnoNWIFS
MBF0PhohdoVJuxCM0ALztR36SQapujoFsw927XLsUP+ewkDGKqDKYO045LG9lQt1
wADIP+mPVVIgv3l95K21cH2a6b8hBSg+I6KAJONdSlc4ujhDtMicGWo6avDS80xf
xG4aM6fWkJgOl37M1JGqHSNPXt/kpvgl7DJgvMyHS1pXZL4eY2bn4KFmmXC48NSL
3VOQiSc+oTaG+rZMl5VSblQpp0VhnlcgFRlO5AowqqbHiTnJAdmnB0gUM5rYLq6/
IVTPYoUw3nlor/PnP29byloW7nMpDPCwkW3RdKbjHAnZJdHSCeRLfhzVpZvXpyio
aLSLzpcGIxyqUteWYURACGqpJ/IsprD4eWZwOLTmyB999g4hS0C/S/yj1xDXUUiN
+4oz5IaxKtVGjNOA3Ws8
=y0gV
-----END PGP SIGNATURE-----

Verifying this file on a third server where my hasn't been imported at all shows:

gpg: Signature made Sat Mar 12 13:41:58 2016 CET using RSA key ID 852109AA
gpg: Can't check signature: No public key

Is it correct that I should now make the output of gpg -a --export 7235F333 available and update it every time I add a new subkey, got the (primary) key signed by someone else etc.? And people who downloaded the public key once should repeat that from time to time to check whether a subkey has been revoked? Which keyservers should I send it to? And which Android-related keys do you trust, i.e. who do you think should sign my key to make it trustworthy to you?

The key fingerprint is 0DC8 2B3E B1C4 6D48 33B4 C434 E82F 0871 7235 F333, but this information alone won't really help someone, it's just for verifying that the public key hasn't been tampered with, as the fingerprint could easily be posted to other places for cross-verification, right? And I assume it's static, no matter whether I add new subkeys etc.

To be honest, getting familiar with GPG really takes time, especially if you want to make sure that you don't accidently do something wrong. I hope that at least verifying keys is quickly possible.

[rovo89]

@foresto Any chance you could give me some short feedback on my questions/remarks above?

[foresto]

Sorry; some other matters have been demanding my attention. I'll try to respond soon.

[rovo89]

Sure, no problem. Just FYI, I have gone forward and sent my master key to a PGP keyserver: https://pgp.mit.edu/pks/lookup?op=vindex&fingerprint=on&search=0xE82F08717235F333 I think that should also include the subkey, so it should be enough to verify the signature I posted above.

[foresto]

Nice. Your public keys (both the master and the subkey) have propagated; I see them on several key servers, including the ones at pgp.net, gnupg.net, and ubuntu.com. With it added to my keyring, I was able to verify that the signature you posted above matches the copy of xposed-v80-sdk23-arm.zip that I downloaded from xda-developers. GPG correctly warns me that although the signature matches the key, I do not yet have any indication that the key is really yours. (This is expected, since your key and identity haven't been signed by any keys in my web of trust.) So far so good.

You might also consider making the subkey passphrase different from the master key passphrase.

Is it correct that I should now make the output of gpg -a --export 7235F333 available and update it every time I add a new subkey, got the (primary) key signed by someone else etc.?

Yes. You can also send updates directly to the key servers, by using the --send-keys option.

And people who downloaded the public key once should repeat that from time to time to check whether a subkey has been revoked?

Yes. Alternatively, this can be done for them whenever they refresh their keyrings with the latest updates from the key servers, for example with gpg's --refresh-keys option.

Which keyservers should I send it to?

The one you already used is well-known and should work fine. The SKS Keyserver Pool offers a bunch more: https://sks-keyservers.net/

Since all the major key servers sync with one another, any of them should normally be sufficient. I like to send changes to one server and then look for those changes on a couple of other servers, just to be sure. You might find this interesting: http://security.stackexchange.com/a/82297

And which Android-related keys do you trust, i.e. who do you think should sign my key to make it trustworthy to you?

How about Moxie Marlinspike? Off the top of my head, I'm not sure who else would be a good start for your web of trust. They don't necessarily have to be Android people, though. I'd probably turn to friends and colleagues first, and expand from there. If you ever make it to developer conferences, a key signing party might be worthwhile. Perhaps some Debian developers in your area would be willing:

https://wiki.debian.org/Keysigning/Coordination

By the way, it occurs to me that convincing strangers to sign your key might be easier if the name on it matches your photo ID. I suppose it's not the only way, though.

The key fingerprint is 0DC8 2B3E B1C4 6D48 33B4 C434 E82F 0871 7235 F333, but this information alone won't really help someone, it's just for verifying that the public key hasn't been tampered with, as the fingerprint could easily be posted to other places for cross-verification, right?

The fingerprint is just a hash (message digest) of the key. It's a way for humans to quickly determine whether one key matches another one, without the hassle of a byte-by-byte comparison. For example, if I proved my identity to you in person and showed you the fingerprint of my public key, you wouldn't have to copy my entire key to a thumb drive and carry it home in order to use it later. Instead, you could just write down the fingerprint I showed you, and upon returning home, compare it to the fingerprint of a key found on a key server to assure yourself that it's the same as the key I had when we met.

And I assume it's static, no matter whether I add new subkeys etc.

Right.

To be honest, getting familiar with GPG really takes time, especially if you want to make sure that you don't accidently do something wrong. I hope that at least verifying keys is quickly possible.

It's true. I'm hoping that, as encryption gets more public attention and becomes important to more people, it will spur the development of easier tools and better UI. We're already starting to see some examples of this, like Let's Encrypt and Mailpile. In the mean time, I really appreciate people like yourself who understand its importance and take the time to learn it.

[rovo89]

Thanks for your patience and reply!

You might also consider making the subkey passphrase different from the master key passphrase.

Already done.

By the way, it occurs to me that convincing strangers to sign your key might be easier if the name on it matches your photo ID. I suppose it's not the only way, though.

Well, all the releases I've done so far are associated with my nickname. I think people would be unsure who that person with the real name is, I think there's more trust when they see the name they're already used to. Apart from that, I would like to separate concerns, e.g. by using separate email addresses for Xposed.

That said, I could obviously generate another key for myself and sign the rovo89 key with it. If you trust someone who trusts me (real name), then as far as I understood the chain of trust would make you trust the rovo89 key as well.

By the way, is there an easy way to download all keys required to complete the chain, or otherwise helps the user to confirm the genuity of a key? For example, if there's a trust chain A trusts B trusts C trusts me, and the user already trusts A, can it detect that the keys of B and C need to be downloaded to establish trust in my key?

The fingerprint is just a hash (message digest) of the key.

I mentioned above that I could sign a zip/jar file with the key that I have always used for signing Xposed Installer, and include my key in that file. So if I just included (& signed) my master fingerprint in that file, that should be enough to let people trust the key from the keyservers with the same fingerprint, assuming they trust my Android key, right?

[DavisNT]

Regarding integrity of Xposed binaries themselves I can suggest:

• Publishing Xposed releases also in GitHub (using GitHub as an additional distribution channel). When publishing a release GitHub allows attaching "release binaries" (that can be flashable .zip files, .apk files and I assume their GPG signatures as well) and those "release binaries" are hosted in GitHub (and downloadable via HTTPS). I believe for most security-aware users downloading files from GitHub (via HTTPS) will be enough. A good example of project using this as their main distribution channel is OpenGApps: https://github.com/opengapps/arm/releases
• As an addition to the classical web of trust it is possible to use Keybase. It is a project that allows to "associate" a public key with social media (GitHub, Twitter, Redit and Hackernews) accounts and own websites/domains. As an example my Keybase profile. Many IT security/crypto people use Keybase. @rovo89 I can send you an invite! I strongly suggest not uploading private key to Keybase (that is a completely insecure feature that technically cannot be made secure when using Keybase web interface). I suggest doing all the signing with curl+BASH+Perl command-lines offered by Keybase web interface.
• It would be nice if you could post your public key also in GitHub gist and post an HTTPS link to it (and Keybase if you will decide to use it) on Xposed website.

Of course this will help protecting only Xposed framework and not the modules published in Xposed repo. As the signatures are checked by Android only when updating existing apps (updating existing Xposed modules) technically it is possible to inject malicious code into newly installed modules (while they are downloaded via unencrypted HTTP by the Xposed Installer). The most reasonable protection for this should be HTTPS (the other solution I can imagine involves lots of complex crypto code in Xposed Installer and Xposed website and still would allow attackers to alter Xposed modules during their upload, steal sessions of developers accessing Xposed website etc.).

Comodo SSL certificates from cheapest resellers cost around 20 $ for 3 years. I can donate those 40 $ one time (for Xposed website and download server for first 3 years) if purchasing certificates is the bottleneck here. If XDA will not support HTTPS for download server, then a hybrid solution would be hosting list of modules (currently http://dl.xposed.info/repo/full.xml.gz) on Xposed website (via HTTPS), adding a SHA-256 hash for each module, and verifying the SHA-256 hash on the downloaded file in Xposed installer. I hope this makes sense.

[fschwebel]

Rovo89 I'm sorry for not following the thread I opened. I see you have made great progress in signing the releases with GPG, pretty much following Tails and Debian signing. That's great and it will give insurance on the integrity of the framework apk. @DavisNT is right to refocus the topic on the suggestions that were first discussed (cf the very content of the ticket for the GitHub releases, modules integrity and SSL consideration).

While I do not recommend using Keybase for a few reasons including its fundamental insecure and auto-promoting concept, and the fact it promotes bad practices, that is indeed another way to help creating trust: by linking different accounts together. Regarding the SSL certificate, I am pretty sure the free solution is better, and the donations can be used for example for the hosting itself.

Regarding the whole installer security, a relevant model is the Cygwin one (https://www.cygwin.com/faq.html#faq.setup.install-security), which could you translated in the xposed world as follows: the installer is distributed through SSL, and includes the server's public key. The installer get the package list and its signature, and check it has indeed been emitted by the server. The package list includes lengths and hashes for all modules, that are checked after each download prior to installation. Of course we are talking about multiple layers here, since SSL on the whole process would already cover 80% of the risk.

[fschwebel]

To clarify why I mentioned the server key instead of yours: this key will be used for every update of the repository, which is very likely to be an automated process. Thus this requires you to have a signing key on the distribution (or better, backend) server. Using two keys for apk signing and package list signing limits the exposure of each. That's actually why using GPG increases the security compared to plain SSL: the signing process can occur on another server, and the compromise of the distribution servers (which are very much Xposed) does not lead to a compromise of the user base.

[DavisNT]

Regarding Let's Encrypt, didn't it require scheduling special scripts being scheduled on the server and ran as root? If so, I think use of Let's Encrypt in this case might have some impediments if XDA download server and server hosting Xposed websites aren't operated by @rovo89. From the other hand cheap Comodo certificates are ordinary certificates - they can be issued by validating ability to receive e-mail or add DNS records to the domain and can be installed on any system supporting HTTPS.

Regarding Keybase, @fschwebel do you see any ways how Keybase (if used only via web interface, without uploading of private key) can be more dangerous than just another keyserver? I think that the overall idea of Keybase (linking public key to social accounts in a standardized way, by publicly proving ownership of the key and accounts) is just great, but of course their offer to upload the private key is just foolish. As I mentioned, lots of crypto people (e.g. authors of the Logjam attack) use it (and probably none of them have chosen to upload their private keys ;) ).

Regarding ideas about signing and distribution mechanism - assuming Xposed website is just a PHP web application accessing additional file storage (called download server), I don't see quite much security advantages of the complex signing/distribution mechanism over a simple HTTPS (preferably with certificate pinning) download.

[fschwebel]

I think we should stay on topic. The official Let's Encrypt client asks for root, but you can use several ACME clients that do not, including in PHP. And if you want to save your bucks, free is good enough. As for Keybase, lots of open-source wizards and cryptonerds don't, let's discuss it elsewhere ;). It's clear that if the security of thousands of people rely on you proving your identity, you should not upload private keys on a business' close-source website (that's what I called insecure, not saying your use is). You can very well not rely on them and post a Gist that you can link from your other accounts. Well, I guess you'd still be promoting GitHub, but whatever. We could endlessly discuss on the tools but the concepts are more important imho.

Your last point is really interesting. We all agreed SSL was the way to go at first. However the current structure with a download/repo server with a simple SSL layer would be compromised if any of the two services is compromised. The signing allow you to split trust and distribution. My first adversity scenario was about protecting against my own ISP, and for that SSL is good enough for the installer, framework and modules in the official repo. I guess we can't do much about the modules downloaded who knows where.

[foresto]

Thanks for your patience and reply!

You're welcome, and thanks back. I think your project is an important one, mainly because pairing it with XPrivacy is the only auditable way I know to take control of Android's broken app permissions system. Secure distribution is important, of course, for assuring users and code auditors that they're actually using and examining the same code.

That said, I could obviously generate another key for myself and sign the rovo89 key with it. If you trust someone who trusts me (real name), then as far as I understood the chain of trust would make you trust the rovo89 key as well.

That's the general idea, though it might take more signatures than just yours. Each user can choose how many trusted third parties must sign a stranger's key before they trust it. (See gpg's --completes-needed and --marginals-needed options.)

By the way, is there an easy way to download all keys required to complete the chain, or otherwise helps the user to confirm the genuity of a key? For example, if there's a trust chain A trusts B trusts C trusts me, and the user already trusts A, can it detect that the keys of B and C need to be downloaded to establish trust in my key?

I haven't used them, but check out these gpg options: --keyserver-options auto-key-retrieve --auto-key-locate

I mentioned above that I could sign a zip/jar file with the key that I have always used for signing Xposed Installer, and include my key in that file. So if I just included (& signed) my master fingerprint in that file, that should be enough to let people trust the key from the keyservers with the same fingerprint, assuming they trust my Android key, right?

Just to be clear, I think you're suggesting this:

• Include your new (public) signing key and/or fingerprint in a zip archive.
• Sign the archive with the old key used to sign past Xposed releases.
• Tell long-time users to verify the signature on the archive and compare that signature's key to the one they've seen on past releases, to establish that you own the new key distributed in the zip archive (and key servers).

I suggest including/signing your entire new key, not just its fingerprint, to guard against future preimage and collision attacks. Assuming you do that, I believe your plan will work as intended.

By the way, you wouldn't really need to use a zip/jar archive for that; you could just distribute a signed key file instead. An archive would allow you to conveniently distribute a software release along with the new key, I suppose. If that's your goal, you could even do this for multiple releases, so people who miss one are more likely to get the message.

Have you generated key revocation certificates for all your keys yet, and stored them someplace safe, in case you ever lose your keys?

[foresto]

I see the latest builds are being announced with gpg signatures. Thanks; that's a step in the right direction.

Where can I find a signature for the Xposed Installer? There's no .asc file for it on the page I linked above.

Is your key fingerprint announced on any other websites? The forum thread I linked has no protection against MITM attacks, so there's no way for a viewer to know that he's reading what you wrote. Publishing your key in several places would be helpful, as would using https (which is weak protection, but better than nothing).

[schnurentwickler]

Is there any progress in validating the XposedInstaller? Even it is a ,well... especially it is a closed source apk / App, it should be proofed that it is compiled from the original author of the code. Who can confirm that a modified XposedInstaller App does not download additional code through the xposed-module-functionality and hide it?