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, etc. funktionieren. Der Schwerpunkt dort liegt darauf öffentlich zu arbeiten und alles öffentlich zugänglich zu machen. Wir schließen Source 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 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 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.

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 Betreuer 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 Betreuern 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 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.

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 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.

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 glauben, 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.

Bestimmte Sicherheitsinstrumente werden diese Internetseite melden, weil hier noch TLSv1.1 and TLSv1.0 unterstützt wird. Wichtiger ist, diese Seite unterstützt TLSv1.3 and TLSv1.2, von denen beide Abwärtsschutz bieten. Zusätzlich deaktivieren die modernsten Browser sowie F-Droid-Clients TLSv1.1 und TLSv1.0 komplett, sodass es unmöglich wird, jene Geräte dazu zu zwingen, diese anfälligen TLS-Versionen zu verwenden. Somit sind eigentlich die einzigen Verbindungen, die alte TLS-Versionen verwenden, jene durch alte Versionen, die diese brauchen um zu funktionieren. Sollten Sie noch ein Gerät verwenden, das noch TLS 1.0 or 1.1 nutzen muss, dann gibt es bereits so viele bestens bekannte Sicherheitsrisiken, dass diese eine nicht mehr sonderlich interessant ist.

Wenn Sie testen möchten, ob Ihr Browser noch TLS 1.0 oder 1.1 unterstützt, klicken Sie auf die Links unten und beobachten Sie, ob Sie eine Fehlermeldung auslösen.

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

F-Droid wird durch Ihre Spenden unterstützt!

Connect

mastodon
@fdroidorg@floss.social

Neuigkeiten

Zuletzt aktualisiert

omWeather

Wetter und Regenradar für jeden Ort - weltweit

FREE Browser

Datenschutzorientierter Webbrowser mit Skriptunterstützung im Greasemonkey-Stil

Gauguin

Ein sudoku-ähnliches Logikspiel

Neuvorstellungen

FREE Browser

Datenschutzorientierter Webbrowser mit Skriptunterstützung im Greasemonkey-Stil

Gauguin

Ein sudoku-ähnliches Logikspiel

Hamfisted

Trainiere für die Amateurfunkprüfung