Deutsches eIDAS-E-Identitäts-Wallet: Geräte-Sicherheitsprüfung auf Basis von Apple- und Google-Konten

 (bmi.usercontent.opencode.de)
1 Punkte von GN⁺ 24 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • Das deutsche National EUDI Wallet wahrt die Integrität der elektronischen Identitätsprüfung über ein System zur Verwaltung von Sicherheitslücken auf Mobilgeräten (MDVM)
  • MDVM erkennt Schwachstellen in Betriebssystem und Hardware Key Store (HKS) und blockiert bei hohem Risiko die Nutzung von Authentifizierungsschlüsseln
  • Unter Android werden Google Play Integrity API und KeyAttestation, unter iOS Apple DeviceCheck·AppAttest zur Prüfung der Geräteintegrität genutzt
  • Durch diese Struktur ist bei der Nutzung der eID-Funktion zwingend ein kontobasierter Verifizierungsprozess über Apple oder Google aktiv
  • Das Gesamtsystem ist darauf ausgelegt, Schlüsselkopien und -missbrauch durch Angreifer zu verhindern und eID-Authentifizierung mit hohem Vertrauensniveau aufrechtzuerhalten

Konzept für das Schwachstellenmanagement mobiler Geräte (Mobile Device Vulnerability Management, MDVM)

  • MDVM ist innerhalb der Architektur des deutschen National EUDI Wallet ein System, das die Sicherheitslücken auf Benutzergeräten fortlaufend überwacht und die Integrität der Authentifizierungsmittel aufrechterhält
  • Erkennt bekannte Schwachstellen in HKS (Hardware Key Store) und Betriebssystem (OS) und blockiert bei hohem Angriffsrisiko die Nutzung von RWSCA-/RWSCD-Schlüsseln
  • Dadurch wird im Prozess der elektronischen Identifizierung (eID) ein hohes Vertrauensniveau gewahrt und Schlüsselkopien bzw. -missbrauch durch Angreifer verhindert
  • MDVM besteht aus vier Funktionen: Prüfung des Sicherheitsstatus von Gerät und App, Identifikation der Geräteklasse, Schwachstellenprüfung und Nutzungsentscheidung

Motivation

  • Die Wallet Unit stellt über ein öffentliches/privates Schlüsselpaar ein Authentifizierungsmittel bereit, das mit mehreren Identitätsnachweisen (z. B. PID) verknüpft ist
  • Bei der Ausstellung einer PID bestätigt WB (Wallet Backend) gegenüber der PP (Provider Party) per OpenID4VCI Key Attestation, dass der betreffende Schlüssel von einem Authentifizierungsmittel mit einer bestimmten Widerstandsfähigkeit gegen Angriffe kontrolliert wird
  • Gemäß ISO/IEC 18045 und EU-Verordnung 2015/1502 sind für elektronische Identifizierung mit hohem Vertrauensniveau starke Authentifizierungsmittel erforderlich
  • Das Authentifizierungsmittel liefert zwei Garantien
    1. Schutz vor Kopieren und Manipulation des Schlüsselspeichers
    2. Schutz des Benutzer-Authentifizierungsmechanismus vor Angriffen
  • Die erste Garantie kann über ein HSM-basiertes RWSCD umgesetzt werden und ist unabhängig vom Benutzergerät erreichbar
  • Die zweite Garantie hängt von der Sicherheit des Benutzergeräts ab und besteht aus einem Besitzfaktor (HKS-basiert) und einem Wissensfaktor (z. B. Passwort)
  • Für HKS oder OS mobiler Geräte ist eine vorgelagerte Schwachstellenanalyse und Zertifizierung praktisch nicht realistisch; zudem wurden in der Vergangenheit zahlreiche Schwachstellen gemeldet
  • Deshalb wird über ein laufendes Schwachstellen-Monitoring im Betrieb (MDVM) die Angreifbarkeit reduziert und auf unzureichend gesicherten Geräten die Nutzung von RWSCA-/RWSCD-Schlüsseln blockiert

Hauptfunktionen von MDVM

Funktion Beschreibung
Prüfung des Sicherheitsstatus von Gerät/App Prüft Integrität und Echtheit von Gerät und Wallet-App und nutzt dabei Plattform-Sicherheitsfunktionen sowie RASP (Runtime Application Self-Protection)
Identifikation der Geräteklasse Ermittelt verifiziert Gerätemodell, OS-Version und Patch-Stand sowie HKS-Informationen
Schwachstellenprüfung je Geräteklasse Prüft aktuelle Schwachstelleninformationen für OS und HKS
Entscheidung über Geräte-/App-Nutzung Blockiert auf Basis von Sicherheitsstatus und Schwachstelleninformationen auf unzureichend gesicherten Geräten die Prüfung der OpenID4VCI Key Attestation sowie die Nutzung von RWSCD-Schlüsseln

Erfasste Signale

  • Die erfassten Signale werden für Threat Response, Identifikation der Geräteklasse und Plausibilitätsprüfung (plausibility check) verwendet

  • Wichtige Signalquellen: KeyAttestation, PlayIntegrity, DeviceCheck, RASP, LPADB, DCVDB

  • Überblick

    Signalquelle Abgewehrte Bedrohungen Synergie Hinweise
    KeyAttestation Rooting, entsperrter Bootloader, Custom ROM, App-Manipulation, Klonen, Emulation, Replay-Angriffe usw. LPADB, RASP Wird als Eingabe für DCVDB verwendet
    PlayIntegrity App-Manipulation, Replay, Rooting, Custom ROM, MDVM-Bewertung auf Basis des Google-Backends, Tools zum Credential-Diebstahl, Overlay-Angriffe usw. KeyAttestation, RASP Prüfung des Bootloader-Status erforderlich
    iOS DeviceCheck Replay, Zertifikatsmanipulation, Proxy-Angriffe, App-Manipulation RASP Unzureichende Absicherung der Geräteintegrität
    LPADB Verschleierung von Rooting mithilfe öffentlich gewordener KeyAttestation-Schlüssel KeyAttestation -
    DCVDB Erkennung unsicherer Geräte auf Basis bekannter Schwachstellen KeyAttestation, RASP Hohe Genauigkeit bei der Identifikation der Geräteklasse wichtig
    RASP Erkennung von App-Hooking, Debugging, Rooting und Emulation - Fortlaufende Überwachung der Integrität zur Laufzeit

Android-KeyAttestation-Signale

  • Identifiziert über hardwaregestützte Verifizierungsinformationen auf HKS-Basis Gerätemodell, OS-Version, Patch-Stand, Bootloader-Status usw.
  • Wichtige Signalpunkte
    • SecurityLevel: Identifikation des HKS-Typs (TrustedEnvironment, StrongBox)
    • attestationIdModel/Product/Device: Identifikation des Gerätemodells
    • osVersion / osPatchLevel: OS-Version und Stand der Sicherheits-Patches
    • RootOfTrust: Status von Bootloader und Verified Boot
    • AttestationApplicationId: App-Paketname, Version, Hash des Signaturzertifikats
  • Die Sperrliste für Key-Attestation-Zertifikate von Google wird nur langsam aktualisiert, sodass öffentlich geleakte Schlüssel weiterhin nutzbar sein können
  • Bei einigen Geräten können bestimmte Identifikationsfelder fehlen, daher müssen alle drei Felder ausgewertet werden

Android-PlayIntegrity-Verdict-Signale

  • Prüft über die Google Play Integrity API die Integrität von App und Gerät
  • Wichtige Signalpunkte
    • appRecognitionVerdict: Ob die App original ist
    • deviceRecognitionVerdict: Vertrauensniveau des Geräts (z. B. MEETS_STRONG_INTEGRITY)
    • appLicensingVerdict: Ob die App über den PlayStore installiert wurde
    • playProtectVerdict: Risikobewertung durch Play Protect
  • MEETS_STRONG_INTEGRITY setzt Sicherheits-Patches innerhalb der letzten 12 Monate voraus
  • Zur Sicherstellung der Signalvertrauenswürdigkeit sind Signaturprüfung und Entschlüsselung erforderlich
  • Die internen Bewertungsmethoden des Google-Backends sind nicht offengelegt

Android RASP

  • Eine konkrete Lösung steht noch nicht fest; derzeit werden die benötigten Funktionen definiert
  • Erkennungsfunktionen
    • App Hooking/Debugging: Erkennung dynamischer Manipulation (Frida, Xposed usw.)
    • App Repackaging/Tampering: Erkennung von App-Manipulation und erneuter Signierung
    • UD Rooting/Emulation: Erkennung von Rooting, Virtualisierung und Automatisierungsumgebungen
  • RASP bietet Integritätsüberwachung zur Laufzeit und pflegt zusätzlich zur Google-Sperrliste eine separate Blocklist, um Angriffe mit geleakten Schlüsseln zu verhindern

iOS DCDeviceCheck.AppAttest Attestation

  • App-Authentifizierungsstruktur über Secure Enclave und Apple-Server
  • Wichtige Signale
    • attestationObject: Belegt, dass der App-Attest-Schlüssel in der Secure Enclave erzeugt wurde
    • credentialId: Kennung des App-Attest-Schlüssels
    • RP ID: App-ID-Präfix + Bundle ID der App
  • Apples Risikometrik (receipt metric) kann zur Erkennung von Proxy-Angriffen genutzt werden, es fehlen jedoch klare Kriterien, und durch die Kommunikation mit Apple-Servern besteht ein Risiko der Preisgabe personenbezogener Daten
  • Unter iOS können hardwaregestützte Informationen zu Gerätemodell sowie OS-Version/Patch-Stand nicht bereitgestellt werden; sie lassen sich nur über OS-Abfragen ermitteln

iOS DCDeviceCheck.AppAttest Assertions

  • Signaturbasierte Verifizierungsstruktur, die mit einem App-Attest-Schlüssel erzeugt wird
  • Wichtige Signale
    • assertionObject: Enthält die Signatur zur Challenge
    • keyId: Kennung des App-Attest-Schlüssels
    • counter: Anzahl der Signaturen; muss monoton steigen
  • Ein sprunghafter Anstieg des Zählerwerts kann auf einen Proxy-Angriff hindeuten, ein Rückgang auf einen möglichen Replay-Angriff

iOS RASP

  • Erfordert ähnliche Erkennungsfunktionen wie unter Android
    • App Hooking/Debugging, App Repackaging, App Tampering, UD Rooting, UD Emulation
  • Apples App Sandbox, Code Signing und System Integrity Protection bieten nur Schutz zum Installationszeitpunkt und keine Erkennung von Rooting, Hooking oder Laufzeitmanipulationen
  • RASP ergänzt dies durch Integritätsüberwachung während der Laufzeit
  • Laut Apple-Dokumentation kann App Attest „auf einem legitimen Gerät ausgeführte manipulierte Apps keine gültige Assertion erzeugen lassen“

Fazit

  • MDVM bewertet den Sicherheitsstatus von Geräten in Echtzeit und blockiert die Nutzung von Authentifizierungsschlüsseln in Umgebungen mit hoher Angriffsgefahr, um so die Verlässlichkeit des elektronischen Identitätssystems zu erhalten
  • Unter Android wie iOS entsteht durch die Kombination von Plattform-Sicherheitsfunktionen und dynamischem Schutz auf RASP-Basis ein System zur Prüfung der Geräteintegrität
  • Es besteht eine Abhängigkeit von den Backend-Verifikationssystemen von Google und Apple; die nicht offengelegten internen Bewertungsmethoden bleiben ein potenzieller Unsicherheitsfaktor

Verwandte Beiträge

1 Kommentare

 
GN⁺ 24 일 전
Hacker-News-Kommentare

  • Die eIDAS-2.0-Spezifikation verlangt keine bestimmte Hardware
    Sie ist lediglich eine Struktur zur Speicherung verifizierbarer Nachweise und kryptografisch signierter Zertifikate
    Es wirkt wie Faulheit, dass das deutsche Implementierungsteam die Klausel umgehen will, wonach „ein Mechanismus implementiert werden muss, mit dem der Nutzer die Echtheit der Wallet Unit verifizieren kann“
    Relevante Dokumente finden sich im EUDI Architecture and Reference Framework

    • In der Referenzimplementierung sieht man, dass die Maintainer die Google-Abhängigkeit nicht entfernen wollen
      Warum, ist unklar, aber wenn etwas grundlos fortbesteht, gibt es am Ende doch einen Grund
      Siehe das GitHub-Repository
    • In Abschnitt 5.4 zu Attestation Rulebooks und Attestation Schemes sind die entsprechenden Regeln festgelegt

  • Als deutscher Implementierer kann ich sagen, dass gemäß der eIDAS-Durchführungsverordnung ein Attestation-Mechanismus verwendet werden muss
    Das funktioniert nicht ohne Unterstützung des Betriebssystems
    Uns ist bewusst, dass die aktuelle Beschränkung auf Google/Android nicht optimal ist, und Unterstützung für andere OS wie GrapheneOS ist ebenfalls geplant
    Im Moment ist das nur eine Frage der Prioritäten, nicht mangelnden Problembewusstseins

    • Von Produkten zweier US-Unternehmen abhängig zu sein, ist nicht nur „nicht gut“, sondern ein ernstes Problem
      Es gibt viele Fälle gesperrter Konten, und so eine Abhängigkeit wäre besser gar nicht erst vorhanden
    • Unter dem Aspekt der Zugänglichkeit und des Verstoßes gegen den Geist von eIDAS gibt es auch rechtswidrige Elemente
      Am Ende werden alle Bürger den AGB von Google und Apple unterworfen, und bei einer Kontosperrung ist der Zugang zu eID-Diensten unmöglich
      Technisch existieren Alternativen, daher ist es deine Verantwortung, eine solche Lösung zu finden
    • Als deutscher Bürger möchte ich fragen: Warum macht man weiter, obwohl man weiß, dass es nicht für alle Bürger funktionieren wird?
      Ich bin von AOSP-basiertem Android ohne Google Play auf Ubuntu Touch gewechselt und plane künftig den Umstieg auf postmarketOS
    • Den Zugang zu einem Google-Konto zu verlieren, ist viel zu einfach. Eine Wiederherstellung ist oft unmöglich
      Angesichts solcher Situationen und geopolitischer Risiken lässt sich die Abhängigkeit von einzelnen Unternehmen nicht rechtfertigen
      Außerdem gilt unter Entwicklern die Erfahrung, dass „provisorische Lösungen die dauerhaftesten sind“
    • Warum wechselt man überhaupt zum Wallet-Modell, wenn Probleme bereits mit der Mobile-ID von eIDAS 1 (SIM-basiert) oder Smart-ID (serverseitige Schlüsselverwaltung) gelöst wurden?
      Es gibt keinen Grund, von den Backends zweier US-Unternehmen abhängig zu sein

  • Attestation selbst sollte abgeschafft werden
    Eine App sollte nicht wissen dürfen, auf welchem Gerät sie läuft
    Der Nutzer kann sein Gerät selbst absichern, und der Entwickler muss höchstens Empfehlungen geben
    Es sollte in jeder Umgebung laufen können: auf GrapheneOS, mit Root, im Emulator, auf einer Linux-Kompatibilitätsschicht usw.

    • Genau, es ist mein Gerät, also sollte ich es so nutzen dürfen, wie ich will
      Dass eine App automatisch prüft, ob sie von US-Big-Tech „zertifiziert“ ist, ist unnötig
    • Das Konzept von Gerätevertrauen ist selbst eine Illusion
      Die Geschichte gerooteter Konsolen und Smartphones zeigt, dass keine Sicherheit perfekt ist
      Sinnvoller wäre es, Nutzern optional die Möglichkeit zu geben, ihre Identität an ein Gerät zu binden, wenn sie das möchten
    • Natürlich darf man rooten oder modifizieren, aber man muss die Folgen tragen
      Wenn eine App ihre eigene Integrität nicht prüfen kann, sind manche Funktionen aus Sicherheitsgründen unmöglich
      So wie physische Ausweise Vorgaben bei Form oder Größe haben, sind auch gewisse Einschränkungen nötig
    • Die Erbsünde des modernen Computings ist, dass „Sicherheitselemente“ eher für Hersteller als für Nutzer entworfen wurden
      Dass solche Elemente seit der NGSCB-Zeit nicht gesetzlich verboten wurden, war der Anfang des Problems

  • Was passiert, wenn man sein Google-/Apple-Konto verliert?
    Wenn man wie ein Richter des Internationalen Strafgerichtshofs sanktioniert wird, verliert man den Zugang zu eIDAS
    Dass die europäische Gesellschaft weiterhin in einer Struktur lebt, die von US-Unternehmen abhängt, ist eine widersprüchliche Realität

    • Auch ohne prominent zu sein, kann man durch automatisierte Kontosperrungen sozial ausgeschlossen werden
      Dass zwei ausländische Unternehmen Überwachungs- und Kontrollmacht haben, ist gefährlich
    • „Wenn Europas Hauptstadt in Washington liegt“, ist so etwas vielleicht selbstverständlich
    • Dann kann man wohl auch kein Waymo mehr nutzen

  • Es ist schockierend, wie wenig öffentlichen Widerstand es gegen solche Politik gibt
    Als Elternteil verstehe ich, dass man die Internetnutzung von Kindern kontrollieren will,
    aber am Ende übernimmt der Staat Aufgaben der Eltern, während Freiheit und Privatsphäre verloren gehen

    • Die meisten Menschen verstehen nur abstrakt, welche Auswirkungen das auf ihr Leben hat
      Solange es nicht wie „die Regierung liest meine WhatsApp-Nachrichten“ als konkrete Bedrohung erscheint, reagieren sie nicht
    • In Deutschland wird die Aufmerksamkeit durch ermüdende Debatten wie Tempolimits zerstreut
      Die Politik nutzt dieses Durcheinander, um die eigentlichen Probleme zu verdecken
    • Viele Eltern befürworten eher Beschränkungen des Online-Zugangs
      Sie möchten, dass Kinder vor dem Aufmerksamkeitsraubbau großer Konzerne geschützt werden
      So wie es in der realen Welt Altersgrenzen gibt, muss das online nicht anders sein
    • Die Menschen sind in ihren eigenen Filterblasen gefangen und hören von solchen Themen gar nichts
      Mit Blick auf die Zukunft der Demokratie ist das sehr besorgniserregend
    • Die EU funktioniert faktisch als Lobby-Plattform
      Bürgerlobbying ist zwar möglich, erfordert aber Kosten und Koordination, weshalb Großunternehmen dominieren
      Kürzlich gab es auch einen Vorfall, bei dem EU-Digitalinfrastruktur von einer Hackergruppe kompromittiert wurde
      Zugehöriger Artikel

  • Anforderungen an bestimmte Hardware oder Software sind unvernünftig
    Alle Bürger sollten die Computer benutzen können, die sie möchten
    Für Authentifizierung reichen Passwörter oder Schlüsselpaarverfahren aus, und wer will, kann TOTP oder Sicherheitsschlüssel ergänzen
    Es scheint, als habe man vergessen, dass es auch Computer außerhalb von Smartphones gibt

    • Die EU will zwar ein von VISA und MasterCard unabhängiges Zahlungssystem schaffen, am Ende bleibt aber eine Abhängigkeit von App-Stores
      Ohne Apple- oder Google-Konto wären selbst Zahlungen in digitalem Euro unmöglich
      Erstaunlich, dass Politiker und Banken nicht zwei oder drei Schritte vorausdenken
    • Die EU-Politik bewegt sich nicht in Richtung „autonome Risikobewertung durch den Nutzer“,
      sondern dahin, dass Dienstanbieter die Nutzer schützen müssen
      Dadurch sind Beschränkungen unterstützter Plattformen letztlich unvermeidlich
    • Die Forderung, es müsse „auf jedem Computer laufen“, ist unrealistisch
      Rechtlich heißt das schließlich nicht, dass es auf einem Apple II funktionieren muss

  • Sanktionierte Personen oder bestimmte Gruppen haben womöglich keinen Zugang zum Play Store,
    sodass bereits die Installation der eIDAS-App unmöglich sein könnte

    • Wenn ein Konto nötig ist, dann wohl ja.
      Wenn man sich jüngste Fälle der Löschung von Konten politischer Gegner ansieht, wäre das für manche Behörden vielleicht sogar willkommen
    • Aber der Schutz privater Schlüssel ist zentral
      Dafür braucht es Sicherheitsgeräte wie Smartcards, weshalb vollständig offene Umgebungen riskant sind
      Ich verstehe den Wunsch, „alternatives Android“ zu verwenden, aber man sollte wissen, dass das eine unsichere Umgebung ist

  • Ich frage mich, wie viel Budget die EU für so ein System verschwenden wird
    Wer das überhaupt braucht, ist mir nicht klar

  • Self Sovereign Identity (SSI) ist die einzige echte Lösung
    Die Identität einer Person sollte nicht von irgendeiner Institution oder Firma abhängig sein
    Identität sollte einfach „ich selbst“ sein
    Wir brauchen keine Google ID oder Apple ID, sondern eine selbstsouveräne Identität

    • Aber „Ich bin einfach ich“ ist keine realistische Form der Identitätsprüfung
      In einer Bar kann man das nicht statt eines Ausweises sagen
      Innerhalb des Gesellschaftsvertrags braucht es eine funktionale Identitätsprüfung
    • Die EU hat bereits 2019 ESSIF (European Self-Sovereign Identity Framework) geschaffen
      Die Infrastruktur existiert also seit sieben Jahren; man kann nicht einfach nur sagen, die Regierung sei unfähig

  • Es wirkt, als sei es Zeit für einen „digitalen Reichstagsbrand“
    Ich möchte fragen, wann Deutschland endlich aufhört, seine Gewohnheit der Geschichtswiederholung fortzusetzen