F-Droid

Sicherheitsmodell

Die Sicherheitsarchitektur basiert auf der Integration von Modellen, die sich in Debian und The Update Framework bewährt haben, in das, was das Android-OS bereits mitbringt. Die Art und Weise wie F-Droid agiert, ist größtenteils von de facto Sicherheitsmodellen beeinflusst, wie sie in angesehenen GNU/Linux-Distributionen wie Debian, Fedora, Ubuntu, usw. funktionieren. Der Schwerpunkt dort liegt darauf öffentlich zu arbeiten und alles öffentlich zugänglich zu machen. Wir schließen Quell-Tarballs und Build-Protokolle ein, wenn wir Binärdateien veröffentlichen. Diese werden so lange wie möglich für retrospektive Prüfungen archiviert. Und all dies wird an vielen, über das Internet verteilten Plätzen von vielen verschiedenen Parteien gespiegelt.

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

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 Quellcode 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 Quellcode. 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-Tools freie Programme sind und auf eine einfache Einrichtung ausgelegt, sind die Hürden für eine automatisierte Auditierung ziemlich niedrig. Menschen in verschiedenen Teilen der Welt mit unterschiedlichen Risikoprofilen können so Verifikationsserver betreiben, um weitergehende vertrauenswürdige Informationen bereitzustellen.

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

App-Signatur

  • Apps können mittels der entwicklereigenen Signaturen vertrieben werden, wenn die Builds vollständig reproduzierbar sind.
  • Standardmäßig erzeugt und verwaltet der “publish”-Server einen Signierschlüssel für jede einzelne Anwendung. Diese Signierschlüssel werden nur dann zwischen Anwendungen ausgetauscht, wenn sie mit dem Mechanismus keyaliases in config.yml speziell dafür konfiguriert wurden.
  • Alle Anwendungen werden mit dem für diese Anwendung bestimmten Schlüssel signiert, es sei denn, der Upstream speziell verlangt, dass mehrere Anwendungen mit demselben Schlüssel signiert werden und die Maintainer von fdroiddata genehmigen dies.
  • Für f-droid.org werden alle App-Signaturen auf einer fest zugeordneten Maschine offline im Air Gap erledigt.
  • Die eigenen Signaturen des Entwicklers können jederzeit zu f-droid.org hinzugefügt werden, sobald reproduzierbare Builds erreicht wurden. Außerdem werden weiterhin mit dem Schlüssel f-droid.org signierte Versionen ausgeliefert.
  • In der offiziellen F-Droid-Client-App ist die Signatur des Entwicklers die Standardeinstellung für Neuinstallationen.
  • Wir empfehlen Entwicklern und Maintainern von Apps, darüber nachzudenken, ob sie eine spezielle Anwendungs-ID für die App verwenden möchten, wenn sie in f-droid.org veröffentlicht wird, um Konflikte mit anderen Versionen zu vermeiden. Ein gängiges Muster ist das Hinzufügen von .fdroid an das Ende der Anwendungs-ID über einen Gradle-Build-Flavor.

Erstinstallationen

Die meisten Nutzer von F-Droid laden die APK von f-droid.org herunter und installieren sie. 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.

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über hinaus macht F-Droid die Vorinstallation in ROM-Projekte so einfach wie möglich. In CalyxOS, Replicant, LineageOS for microG and 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 Quellrepository der App entnommen werden. Diese Daten werden schließlich über f-droid.org an den Android-Client oder den Browser des Benutzers übermittelt.

HTTPS/TLS-Konfiguration

F-Droid hat eine lange Tradition, alle Android-Geräte zu unterstützen, die noch laufen, das bedeutet Kompatibilität so lange wie möglich bereitzustellen. In Anbetracht dessen werden immer noch alte TLS-Konfigurationen unterstützt, was Anwender, solange sie aktuelle Android-Versionen betreiben, nicht gefährdet. Deshalb lassen wir auf unserer Website TLSv1.0 und TLSv1.1 weiter aktiv. Wir denken, dass es für Leute, die ihre Software auf dem neusten Stand halten, kein erhöhtes Risiko besteht. Und ein Gerät mit Android 1.6 sollte in der Lage sein, eine alte Version von F-Droid zu installieren, und einen funktionierenden App-Store haben.

Einige Sicherheitsscanner werden diese Website als unsicher kennzeichnen, da TLSv1.1 und TLSv1.0 weiterhin unterstützt werden. Wichtiger ist jedoch, dass diese Website TLSv1.3 und TLSv1.2 unterstützt, die beide Downgrade-Schutz bieten. Darüber hinaus haben die neuesten Browser und F-Droid-Clients TLSv1.1 und TLSv1.0 vollständig deaktiviert, sodass es unmöglich ist, diese Geräte zum Verwenden dieser anfälligen TLS-Versionen zu zwingen. Die einzigen Verbindungen, die alte TLS-Versionen verwenden, benötigen diese alten Versionen tatsächlich, um zu funktionieren. Wenn du ein Gerät verwendest, das noch TLS 1.0 oder 1.1 benötigt, gibt es bereits so viele bekannte Sicherheitslücken, dass diese eine nicht besonders interessant ist.

Wenn du testen möchtest, ob dein Browser noch TLS 1.0 oder 1.1 unterstützt, klicke auf die unten stehenden Links und prüfe, ob eine Fehlermeldung angezeigt wird.

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 „Bazaar 2“-Projekt schloss ein externes öffentliches Audit von Radically Open Security ein

  4. Die von NLnet geförderten Projekte “Tracking the Trackers” und “The Search for Ethical Apps” haben ein Audit durchgeführt von Radically Open Security bereitgestellt

Apps finden

Spenden

Deine Spenden machen F-Droid möglich!

Connect

mastodon
@fdroidorg@floss.social

Neuigkeiten