Clientseitiges Scannen untersucht Inhalte auf dem Gerät eines Nutzers, wo sie bereits vor dem Senden oder nach dem Empfang lesbar sein können. Dadurch kann ein Offenlegungspfad außerhalb des verschlüsselten Übertragungskanals entstehen. Der Vergleich einer APK-Prüfsumme beweist nicht, dass eine App keinen Scan-Code enthält. Er beantwortet eine engere Frage: ob die ausgewählten Bytes mit einem bestimmten Hashwert übereinstimmen.
Diese Aussagen auseinanderzuhalten macht sowohl Verschlüsselung als auch Softwareprüfung nützlicher.
Warum Scannen auf einem Gerät die Datenschutzgrenze verändert
Eine App muss Klartext verarbeiten, um eine Nachricht anzuzeigen oder ein Foto zum Versand vorzubereiten. An dieser Stelle kann eine Scan-Funktion arbeiten, selbst wenn die anschließende Netzwerknachricht Ende-zu-Ende-verschlüsselt ist. Was das Gerät verlässt, hängt vom Aufbau des Scanners ab: Er könnte einen Treffer melden, ausgewählte Inhalte hochladen oder andere abgeleitete Informationen senden.
Die Forschungsarbeit Bugs in our Pockets untersucht Risiken wie Missbrauch, Fehlalarme und zusätzliche Angriffsfläche. Das sind Gründe, die Datenflüsse und die Steuerung eines vorgeschlagenen Scan-Systems zu prüfen. Sie belegen weder, dass jede geräteinterne Funktion Überwachung ist, noch, dass ein bestimmtes Gesetz eine allgemeine Scan-Pflicht eingeführt hat.
Eine lokale Funktion unter der Kontrolle des Nutzers ist nicht automatisch mit verpflichtender Meldung gleichzusetzen. Fragen Sie, wer die Analyse auswählt, was sie auslöst, wer ihre Regeln aktualisieren kann und welche Daten das Gerät verlassen können.
Vier unterschiedliche Arten von Softwarebelegen
| Prüfung | Was sie belegen kann | Was sie allein nicht belegen kann |
|---|---|---|
| SHA-256-Prüfsumme | Die Datei entspricht einem vertrauenswürdigen Referenzhashwert | Dass das Referenzprogramm sicher ist oder dem Quellcode entspricht |
| APK-Signaturprüfung | Die Paketsignatur lässt sich prüfen und identifiziert ein Signaturzertifikat | Dass der Unterzeichner vertrauenswürdig ist oder der Code kein unerwünschtes Verhalten zeigt |
| Reproduzierbarer Build | Festgelegter Quellcode und Build-Eingaben können die erwarteten Artefakte erzeugen | Dass der Quellcode frei von Schwachstellen oder schädlicher Logik ist |
| Unabhängige Prüfung und Tests | Erkenntnisse zu einer definierten Version und einem definierten Umfang | Eine dauerhafte Garantie für jede zukünftige Aktualisierung |
Die apksigner-Dokumentation von Android erklärt die Paketprüfung und die Ausgabe von Zertifikatsinformationen. Die Definition von Reproducible Builds erläutert, warum Quellcode, Build-Umgebung und Anweisungen beim Reproduzieren eines Artefakts alle wichtig sind.
Ein Quellcodearchiv und eine daneben angezeigte Prüfsumme sind allein kein Ergebnis eines reproduzierbaren Builds. Ebenso ist eine gültige Signatur einer schädlichen Veröffentlichung weiterhin eine gültige Signatur.
Einen Download prüfen, ohne das Ergebnis überzuinterpretieren
Bestimmen Sie zuerst die gewünschte Veröffentlichung und beziehen Sie ihre APK sowie den erwarteten Hashwert über einen vertrauenswürdigen Vertriebsweg. Berechnen Sie den Hashwert lokal. Weicht er ab, installieren Sie die Datei nicht, solange die Abweichung ungeklärt ist: Eine andere Version, ein unvollständiger Download oder Manipulation können jeweils eine Abweichung verursachen.
Stimmt er überein, halten Sie die Veröffentlichung und das Ergebnis fest. Damit haben Sie Byte-Gleichheit gegenüber dieser Referenz festgestellt, nicht das Fehlen clientseitigen Scannens. Kann derselbe Angreifer sowohl den Download als auch die angezeigte Prüfsumme ersetzen, kann der Vergleich trotzdem erfolgreich sein. Unabhängige Referenzen, Kontinuität des Signaturschlüssels und Veröffentlichungstransparenz helfen bei unterschiedlichen Teilen dieses Vertrauensproblems.
Für die Behauptung einer Übereinstimmung zwischen Quellcode und Binärdatei sollten Sie nach dokumentierten Build-Anweisungen und unabhängig reproduzierten Ergebnissen für die tatsächliche Veröffentlichung suchen. Leiten Sie diese Eigenschaft nicht aus den Worten „Open Source“ ab.
Aktualisierungen bleiben wichtig
Die Softwareverteilung kann angegriffen werden, aber Sicherheitsupdates auf unbestimmte Zeit zu meiden ist keine solide allgemeine Schutzstrategie. Updates beheben auch ausnutzbare Schwachstellen. Nutzen Sie einen vertrauenswürdigen Update-Kanal, beachten Sie relevante Sicherheitshinweise und prüfen Sie Veröffentlichungsbelege, wenn Ihr Risiko dies rechtfertigt. Eine alte Version mit einem bekannten Fehler ist nicht allein deshalb sicherer, weil ihre Prüfsumme einmal übereinstimmte.
Was Livaras Proof Lab belegt
Livaras Proof Lab bietet einen lokalen APK-Hashvergleich und kryptografische Demonstrationen im Browser. Die Seite erklärt, dass sie die vollständigen LVR1/LGS1-Ratchets nicht ausführt und kein Protokollaudit darstellt. Auch das Bedrohungsmodell erläutert die Grenze, wenn ein Angreifer sowohl eine Datei als auch ihren erwarteten Hashwert ersetzen kann.
Innerhalb ihres Umfangs sind diese Prüfungen nützlich. Sie beweisen nicht, dass ein eingerichtetes Telefon frei von Schadsoftware ist, dass Livara unabhängig reproduzierbare Veröffentlichungen hat oder dass seine Anwendung kein nicht offengelegtes Verhalten enthalten kann. Lesen Sie die Sicherheitsdokumentation gesondert zu den beanspruchten Grenzen des Nachrichtenschutzes.
Die richtige Frage ist nicht, ob ein Siegel „geprüft“ sagt. Sie lautet, welche Behauptung anhand welcher vertrauenswürdigen Referenz für welche genaue Veröffentlichung getestet wurde.
