Security Model

The security architecture is based on models proven by Debian, The Update Framework , and others:

While the current setup is already a solid platform, we are implementing a number of improvements:

  • The signed metadata will include list of official mirrors, then the client chooses mirrors based on availability and freshness based on local criteria like whether Tor is in use, closest on the internet, etc.
  • We are also moving the standard HTTP “etag” cache check from the server to the client so it cannot be abused to track users
  • pinned TLS certificate built into the client app

In order to defend against an attacker that holds the signing keys for the app repository, there must be a trustworthy source of information to compare against. Reproducible builds means that anyone with the same source code will produce the exact same binary. When paired with an auditing system, it is easy to catch malware inserted in the build process, rather than the source code, like XCodeGhost. Reproducible builds also makes it possible to have all builds of a release binary have the exact same hash. Then any app repository can build apps only from source code, and have a source of verification data from any other app repository building the same app. Building software from source has become cheap enough that many companies like gitlab.com and Travis CI are offering free, automated build services in the cloud. Since the whole F-Droid toolset is free software and designed to be easy to setup, the barriers to setting up automatic auditing are quite low. People in separate areas of the world with different risk profiles can run verification servers to provide more trustworthy information.

The security model of the Build Server Setup and the Signing Process are documented separately.

Initial Installs

Most users of F-Droid download the APK from f-droid.org and install it. This is a potential vector of attack that built-in app stores do not have. Therefore, many additional security precautions are taken to make it as hard as possible to exploit this vector.

F-Droid as built in app store

When F-Droid is built into Android, either as part of the ROM or by flashing an OTA update, it no longer needs “Unknown Sources” enabled to function. This is the preferred method of operation, so we aim to make it as easy as possible for users to run F-Droid this way. Flashing the OTA package for F-Droid Privileged Extension has the same or lower risk profile as installing the standard “gapps” package that many people flash onto custom ROMs. So this delivery method does not increase the risk profile of those users.

On top of this, F-Droid makes it as easy as possible to build it into ROM projects. It is already included in Replicant, CopperheadOS, LineageOS for microG and Fairphone Open.

Protecting against malicious contributor-generated data

The app descriptions are submitted by all sorts of people, and they can also be taken from the app’s source repository. This data is ultimately delivered to the Android client or the user’s browser via f-droid.org.

Security Audits

  1. There was a quick, informal security audit (archived) done in 2013 by then graduate student Daniel McCarney aka pd0x.

  2. The first “Bazaar” project funded by Open Tech Fund included an external public audit from Cure53

  3. The second “Bazaar2” project funded by Open Tech Fund included an external public audit from Radically Open Security