Warum Verschlüsselung von Modellen auf dem Gerät die API-Autorisierung nicht ersetzen kann

Dekonstruktion mobiler KI-Anwendungen in sieben Asset-Klassen

Die Sicherheit mobiler KI wird oft fälschlicherweise darauf reduziert, ob das Modell verschlüsselt ist. Tatsächlich umfasst die Angriffsfläche mindestens Modelldateien, Inferenz-Laufzeiten, Eingabevorverarbeitung, Ausgabennachverarbeitung, Prompts oder Geschäftsregeln, Remote-API-Anmeldedaten, Benutzerdaten und Logs. Jede Asset-Klasse birgt bei einem Leak unterschiedliche Konsequenzen, verfügt über eigene Update-Mechanismen und unterliegt separaten Verantwortlichkeiten.

Das Kopieren von Modellgewichten kann zu Diebstahl geistigen Eigentums und Verlust von Geschäftsfähigkeiten führen; das Ändern von Prompt-Vorlagen oder Nachverarbeitungslogik kann das Geschäftsverhalten verfälschen; das Lecken langlebiger API-Schlüssel kann direkt zu finanziellen Verlusten, unbefugtem Datenzugriff oder Ressourcenmissbrauch führen; Eingabe-/Ausgabe-Logs können private Benutzerdaten enthalten. Der Schutz nur der Modelldatei deckt diese verbleibenden Risiken nicht ab.

Ein Asset-Register muss Speicherort, Generierungsquelle, Übertragungspfad, Nutzungsmuster zur Laufzeit, Update- und Rollback-Mechanismen, das Prinzip der geringsten Rechte, den Umfang der Protokollierung und Aufbewahrungsfristen dokumentieren. Assets ohne definierten Lebenszyklus sollten nicht allein durch das Aktivieren eines Verschlüsselungsschalters als geschützt gelten.

Modelldateien müssen während der Laufzeit zu nutzbarem Material werden

Egal ob Core ML, LiteRT oder andere On-Device-Runtimes verwendet werden: Modelle müssen geladen, geparst und in die Berechnung einbezogen werden. Verschlüsselung auf Dateiebene erschwert das direkte Kopieren aus Installationspaketen oder App-Verzeichnissen, kann jedoch nicht verhindern, dass die laufende Anwendung auf Modellmaterialien zugreift. Wenn ein Angreifer den Prozess kontrolliert oder die Laufzeit beobachtet, verlagert sich das Risikomodell von statischen Dateien hin zu Ladevorgängen, Speicherbereich, Funktionsaufrufen und Ausgaben.

Dies bedeutet nicht, dass Modellverschlüsselung wertlos ist. Sie erhöht die Kosten für müheloses Kopieren, verhindert direkte Substitution und bildet Teil einer Defense-in-Depth-Strategie neben Paketschutz, Integritätsprüfungen, Erkennung der Laufzeitumgebung und Versionspaarung. Entscheidend ist, den Nutzen als Erhöhung der Angreiferkosten und Reduzierung der Angriffsfläche (Blast Radius) darzustellen, anstatt zu behaupten, eine Extraktion sei unmöglich.

Modellupdates führen zudem zu Kompatibilitätsherausforderungen. Modellversionen müssen mit Vorverarbeitungslogik, Feature-Shapes, Runtime-Versionen, Hardwarefähigkeiten und Nachverarbeitungsregeln abgestimmt sein. Bei Update-Fehlern sind sichere Rollbacks erforderlich, um zufällige Kombinationen aus alten Modellen und neuer Logik zu verhindern.

Langlebige API-Schlüssel mit hohen Privilegien dürfen keine Client-Geheimnisse sein

Die Android-Sicherheitsdokumentation stellt explizit fest, dass in den Quellcode eingebettete API-Schlüssel nach der Kompilierung der App durch Dekompilierung entdeckt werden können. Verschleierung und Application Hardening können zwar die Kosten für das Auffinden erhöhen, ändern aber nichts daran, dass der Client diese Anmeldeinformationen besitzen und nutzen muss. Solange ein Schlüssel langlebig und hochprivilegiert innerhalb eines generischen Clients bleibt, lässt sich die Auswirkung eines Lecks kaum begrenzen.

Der Android Keystore kann bestimmte Schlüsselmaterialien nicht exportierbar halten, doch die offizielle Dokumentation klärt auf, dass Angreifer bei Kompromittierung des Anwendungsprozesses möglicherweise dennoch in der Lage sind, die Schlüssel der App für Operationen zu nutzen. Er eignet sich zum Schutz gerätegebundener privater Schlüssel und lokaler Verschlüsselung, sollte jedoch nicht fälschlicherweise als sicherer Tresor für beliebige langlebige gemeinsame Geheimnisse für Remote-Dienste interpretiert werden.

Eine robustere Architektur erfordert, dass der Client basierend auf Benutzeridentität und Gerätekontext kurzlebige, eingeschränkte und widerrufbare Token von seinem eigenen Dienst anfordert oder dass serverseitige Proxys risikoreiche Funktionsaufrufe (Function Invocations) von Modellen übernehmen. Der Server muss Kontoautorisierung, Kontingente, Ratenbegrenzung, Modellumfang, Datenumfang und Überwachung anomalen Verhaltens durchsetzen.

• Anmeldeinformationen nach Entwicklungs-, Test- und Produktionsumgebungen isolieren
• Sicherstellen, dass Token nur minimale Modell- und Datenberechtigungen besitzen
• Serverseitigen Widerruf aktivieren sowie Kontingente und Ratenbegrenzungen durchsetzen
• Verhindern, dass Clients langlebige gemeinsame Schlüssel mit hohen Privilegien speichern

request = verify_user_session(input.session)
app = verify_app_evidence(input.attestation)
policy = load_policy(user=request.user, app=app.identity)

if policy.version_state == UNKNOWN:
    return CHALLENGE_OR_LIMIT
if policy.account_scope.allows(input.model_scope) == false:
    return DENY
if policy.risk_score >= HIGH:
    return STEP_UP_VERIFICATION

return issue_short_lived_token(
    scope=input.model_scope,
    quota=policy.quota,
    expires_in=policy.short_window
)

Integritätssignale sollten ausschließlich serverseitige Entscheidungen informieren

Play Integrity liefert Android-Backends Signale zur App-Identifikation, Geräteintegrität, Kontolizenzierung und teilweisen Umgebungsrisiken. Apple App Attest unterstützt den Server bei der Prüfung, ob eine Anfrage von einer gültigen App-Instanz stammt, indem es Geräteschlüssel generiert, Einmal-Challenges ausstellt, die Attestierung serverseitig verifiziert und nachfolgende Assertions verarbeitet. Gemeinsam ist beiden, dass die Nachweise letztlich serverseitig validiert werden.

Diese Mechanismen haben klare Grenzen. Play-bezogene Signale werden durch Vertriebsquellen, Gerätestatus und Dienstbedingungen beeinflusst; die Apple-Dokumentation weist darauf hin, dass App Attest nicht auf allen Gerätetypen unterstützt wird und keine einzelne Richtlinie Betrug vollständig ausschließt. Der Server muss zwischen Bestanden, Fehlgeschlagen, Nicht verfügbar, transienten Fehlern und nicht konfigurierten Zuständen unterscheiden. Er darf „Nicht verfügbar" nicht direkt mit einem Angriff gleichsetzen und keine endgültigen Entscheidungen lokal auf dem Client treffen.

Integritätssignale und Modellverschlüsselung lösen unterschiedliche Probleme. Erstere helfen, Applikationsinstanzen und Laufzeitumgebungen zu verifizieren, während Letztere die Exposition statischer Modelle reduziert. Echte Autorisierung erfordert weiterhin Kontext des Benutzerkontos, Prüfungen geschäftlicher Ressourcen, Versionsvalidierung, Analyse des Anfrageinhalts, Durchsetzung von Quoten und Verhaltenskontext.

Validierung mobiler KI-Anwendungen erfordert statische, laufzeitbezogene und serverseitige Perspektiven

Statische Prüfungen klären, welche Modelle, Konfigurationen, Strings, Credentials und Debug-Ressourcen im Installationspaket vorhanden sind; Laufzeitprüfungen klären, wie Modelle geladen werden, wie Fehler behandelt werden, ob Logs Daten preisgeben und ob Updates zurückgerollt werden können; serverseitige Prüfungen klären, ob Konto-, Versions-, Integritäts-, Quoten- und Datenberechtigungen tatsächlich durchgesetzt werden. Fehlt einer dieser drei Nachweistypen, verzerrt dies die Schlussfolgerungen zugunsten partialer Sichtweisen.

Tests müssen eindeutige Release Candidates und explizite Modellversionen verwenden sowie Zielsysteme, Gerätefähigkeiten, Laufzeit-Backends, Modellquellen und Update-Zustände dokumentieren. Leistung, Speichernutzung und Kompatibilität der On-Device-Inferenz hängen von Modellstruktur, Quantisierung, Hardware und Laufzeit ab; Kennzahlen anderer Modelle oder Geräte dürfen nicht herangezogen werden.

Ausnahmepfade sind kritisch: fehlende oder beschädigte Modelldateien, unterbrochene Updates, nicht unterstützte Laufzeiten, abgelaufene Server-Token, nicht verfügbare Integritätssignale, fehlgeschlagene Log-Uploads und widerrufene Nutzerberechtigungen. Das System muss sicher degradieren und wiederherstellbare Zustände sowohl für Nutzer als auch für Betriebsteams bereitstellen.

Design-Fazit und Umfangsbegrenzungen

Modellverschlüsselung ist sinnvoll, stellt jedoch nur einen Kontrollpunkt im Modell-Lebenszyklus dar. Kommerzielle KI-Apps müssen zudem die Vor- und Nachverarbeitungslogik schützen, verhindern, dass langlebige Schlüssel mit hohen Privilegien auf den Client gelangen, sicherstellen, dass der Server die endgültige Autorisierung vornimmt, Fehlertoleranz für Plattform-Integritätssignale implementieren sowie Nutzerdaten und Logs governen.

Ohne tatsächliche Release Candidates, Modellversionen, Zielgeräte und serverseitige Schnittstellen können wir lediglich die Architektur und ausstehende Validierungspunkte prüfen. Wir können nicht behaupten, Modelle seien extraktionssicher, Schnittstellen missbrauchssicher, Runtime-Injection blockiert oder Leistungsziele erreicht. Derartige Schlussfolgerungen erfordern aktuelle Evidenzpakete.

Der Aktions-Einstiegspunkt für Yudun auf dieser Seite dient der Beantragung von Application Hardening und Kompatibilitätsbewertung; er stellt keine Validierung eines spezifischen Modell-Frameworks oder einer exklusiven KI-Fähigkeit dar. Der Projektumfang muss separat bestätigt werden, nachdem Tech-Stack, Modell-Bereitstellungsmethode und kritische Geschäftspfade eingereicht wurden.

• Führen Sie separate Register für Modelle, Runtimes, Credentials und Daten
• Stellen Sie sicher, dass hochriskante Function Invocations abschließend vom Server autorisiert werden
• Bieten Sie Nichtverfügbarkeits- und Degradationspfade für Plattform-Signale vor
• Ermöglichen Sie Modell-Updates zur Unterstützung von Verifikation, atomarem Wechsel und Rollback
• Binden Sie alle conclusions an spezifische Release Candidates und Modellversionen