- App-Signatur
- Erstinstallationen
- F-Droid als vorinstallierter App-Store
- Schutz vor böswilligen Daten, die von Mitwirkenden erzeugt wurden
- HTTPS/TLS-Konfiguration
- Sicherheitsaudits
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.
- Ein Repo ist, zuerst und vor allen Dingen, dadurch bestimmt, einen einzigartigen Signierschlüssel zu besitzen
- 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
- Ab index-v2 werden Dateien aus dem Repo auf Basis von SHA-256 verifiziert, einschließlich Icons, Screenshots usw.
- index-v2 verwendet alle Algorithmen, die von
apksigner
und
android-23
und jünger unterstützt werden und vertraut auf die Aufrechterhaltung des
momentan gültigen Signier-Algorithmus durch OpenJDK und Google. Beim
Start von index-v2 war der verwendete Signatur-Algorithmus
SHA256withRSA
und der Digest AlgorithmSHA-256
. index-v1 ist durchSHA1withRSA
signiert. Während dies hier geschrieben wird, werden SHA1 immer noch als stark gegenüber Second Preimage Attacks angesehen, was das Maßgebliche für Index-JARs ist. - Produktionssignierung wird durch Reproduzierbare Builds des apksigner von Debian erledigt.
- 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 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.
- 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ü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.
- 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 Bleach und hat eine gute HTTP Inhaltssicherheitsrichtlinie.
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
-
Es wurde ein kurzes, informelles Sicherheitsaudit (archiviert) im Jahr 2013 durch den damaligen Hochschulabsolventen Daniel McCarney, auch bekannt unter pd0x, durchgeführt.
-
Das erste, von Open Tech Fund finanzierte „Bazaar“-Projekt schloss ein externes öffentliches Audit von Cure53 ein
-
Das zweite, von Open Tech Fund finanzierte „Bazaar 2“-Projekt schloss ein externes öffentliches Audit von Radically Open Security ein
-
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