Die Sicherheitsarchitektur beruht auf Modellen, die bei Debian, The Update Framework und anderen erprobt sind:

• HTTPS-Verbindungen als Standard
• der Server funktioniert nur über HTTPS, HTTP fungiert als Weiterleitungsadresse
• Android fordert zwingend, dass alle Apps eine gültige Signatur besitzen, die sämtliche Inhalte der APK-Datei umfasst
• Android überprüft Aktualisierungen anhand der Signatur der installierten App
• Schutz der Datenintegrität durch signierte Metadaten
• signierte Metadaten beinhalten Hashwerte für die App und deren Signierschlüssel
• signierte Metadaten, die auf einem gesonderten Rechner generiert werden (der bei f-droid.org und guardianproject.info komplett offline ist)
• in die F-Droid-App integrierter, öffentlicher Schlüssel zur Überprüfung der Metadaten-Signaturen
• signierte Metadaten enthalten einen Zeitstempel und ein Verfallsdatum
• einfache Tor-Unterstützung über die Einstellungen
• client-side HTTP „etag“ cache check so dass das ETag nicht missbraucht werden kann, um Benutzer zu verfolgen
• Liste der offiziellen Spiegel, die in signierten Metadaten enthalten sind, dann wählt der Client Spiegel basierend auf Verfügbarkeit und Aktualität basierend auf lokalen Kriterien wie z. B. ob Tor verwendet wird

Obwohl das aktuelle Setup bereits eine solide Plattform ist, gibt es eine Reihe von Verbesserungen, die sinnvoll sind:

• bessere Handhabung des Indexablaufs oder auch „max age“
• in den Client integriertes, fest verankertes TLS-Zertifikat

Um Angreifer, die im Besitz des Signierschlüssels für das App-Repository sind, abzuwehren, wird eine vertrauenswürdige Informationsquelle zum Gegenabgleich benötigt. Für reproduzierbare Builds gilt, dass jeder mit demselben Quelltext exakt dieselbe Binärdatei erzeugen wird. Bei Anbindung an ein Auditierungssystem ist es leicht in den Build-Prozess eingeschleuste Schadsoftware, wie XCodeGhost, abzufangen, leichter als im Quelltext. Reproduzierbare Builds machen es außerdem möglich, dass alle Builds einer Binärdateiausgabe genau denselben Hashwert besitzen. Jedes App-Repository kann dadurch nur aus dem Quellcode Apps erstellen und besitzt eine Quelle mit Überprüfungsdaten zu allen anderen App-Repositorys, die dieselbe App herstellen. Softwareherstellung aus dem Quellcode ist so preiswert geworden, dass viele Firmen, wie gitlab.com und Travis CI, kostenlose, automatisierte Build-Leistungen in der Cloud anbieten. Nachdem sämtliche F-Droid-Werkzeuge freie Programme sind und auf eine einfache Einrichtung ausgelegt sind, sind die Hürden für eine automatisierte Auditierung ziemlich niedrig. Menschen in verschiedenen Teilen der Welt mit unterschiedlichen Risikoprofilen können so Prüfserver betreiben, um weitergehende vertrauenswürdige Informationen bereitzustellen.

Die Dokumentation zum Sicherheitsmodell der Build-Server-Konfiguration und des Signiervorganges erfolgt separat.

Erstinstallationen

Die meisten Nutzer von F-Droid laden das APK von f-droid.org herunter und installieren es. Dies ist ein potentieller Angriffsvektor, den vorinstallierte App-Stores nicht haben. Deshalb werden viele zusätzliche Sicherheitsvorkehrungen getroffen, um es so schwierig wie möglich zu machen, diesen Angriffsweg auszunutzen.

• Einschluss in die HSTS preload list, damit gängige Browser ausschließlich HTTPS für alle Verbindungen zu f-droid.org verwenden.
• eine starke TLS/HTTPS-Konfiguration
• eine starke Sicherheitsrichtlinie zu HTTP-Inhalten
• PGP-Signatur der Download-Verknüpfung zur Erstinstallation
• automatisierte regelmäßige und stichprobenartige Auditierungen, dass an F-Droid.apk keine unerlaubten Änderungen vorgenommen wurden
• F-Droid Limited überwacht viele potentielle Phishing-Domänen, wie fdroid.org, f-droid.com und f-dro1d.org. (die Bekanntgabe weiterer wird begrüßt!)
• Die Website wird statisch erzeugt, um die Angriffsfläche in hohem Maße zu reduzieren
• die Website ist komplett funktionsfähig, wenn Javascript im Browser deaktiviert ist, wodurch alle XSS-Angriffsmöglichkeiten beseitigt werden

F-Droid als vorinstallierter App-Store

Wenn F-Droid in Android vorinstalliert ist, entweder als Teil des ROM oder durch Einspielen eines OTA Update, wird die Aktivierung der „Unbekannten Herkunft“ nicht mehr benötigt, damit es funktioniert. Dies ist die bevorzugte Arbeitsmethode, so haben wir uns zum Ziel gesetzt, es Anwendern so einfach wie möglich zu machen, F-Droid auf diese Art zu betreiben. Die Installation des OTA-Paketes für F-Droid’s Rechteerweiterung hat das gleiche wenn nicht niedrigere Risikoprofil wie die Installation des Standard-„GApps“-Paketes, das viele Menschen zu Custom-ROMs flashen. So erhöht diese Bereitstellungsmethode nicht das Risiko für jene Anwender.

Darüberhinaus, macht F-Droid die Vorinstallation in ROM-Projekte so einfach wie möglich. In Replicant, CopperheadOS, LineageOS for microG und Fairphone Open ist es bereits integriert.

Schutz vor böswilligen Daten, die von Mitwirkenden erzeugt wurden

Die App-Beschreibungen werden von allen möglichen Personen eingereicht und können auch aus dem Quell-Repository der App entnommen werden. Diese Daten werden schließlich über f-droid.org an den Android-Client oder den Browser des Benutzers übermittelt.

• der Android-Client führt niemals CSS, Javascript oder gefährliches HTML Tags aus, da es HTML anzeigt via android.text.Html.fromHtml() mit deaktiviertem Laden von Bilddern
• die f-droid.org Webseite schützt vor bösartiger und CSS/HTML/Javascript-Injektion mit einer strikten HTTP Inhaltssicherheitsrichtlinie.
• Repomaker filtert die Texte durch Mozillas Bleiche und hat eine gute HTTP Inhaltssicherheitsrichtlinie.

Sicherheitsaudits

1. Es wurde ein kurzes, informelles Sicherheitsaudit (archiviert) im Jahr 2013 durch den damaligen Hochschulabsolventen Daniel McCarney, auch bekannt unter pd0x, durchgeführt.

2. Das erste, von Open Tech Fund finanzierte „Bazaar“-Projekt schloss ein externes öffentliches Audit von Cure53 ein

3. Das zweite, von Open Tech Fund finanzierte „Bazaar2“-Projekt schloss ein externes öffentliches Audit von Radically Open Security ein