Übersicht

• 1: KI-Klassen
• 2: Schutzziele
• 3: Software-Maßnahmen
• 4: Hardware-Maßnahmen
• 5: Evaluierung
• 6: Empfehlungen
• 7: Best Practices

1 - KI-Klassen

Ziel des Projektes SENSIBLE-KI ist es, KI-Anwendungen im eingebetteten und mobilen Bereich zu schützen. Um eine möglichst standardisierte Absicherung gewährleisten zu können, ist es notwendig, KI-Anwendungen zu systematisieren. Anhand von diskreten KI-Klassen kann dann der Schutzbedarf ermittelt werden.

Basierend auf der Evaluierung einer großen Anzahl von KI-Anwendungen wurden im Projekt die im Folgenden dargestellten Klassen identifiziert. Es handelt sich dabei um eine vertikale (d.h. mehrdimensionale) Klassifizierung, welche auf verschiedenen Eigenschaften der KI-Anwendungen basiert.

Indem eine Anwendung anhand dieser verschiedenen Ebenen eingeteilt wird, kann ihr ganz individueller Schutzbedarf ermittelt werden.

2 - Schutzziele

Ein wichtiger Schritt, um die Sicherheit von Systemen, die Künstliche Intelligenz (KI)-Anwendungen verwenden, zu evaluieren, ist es, konkrete Schutzziele für die KI zu definieren. Anhand dieser können die Anwendungen dann bewertet und ihr Schutzbedarf bestimmt werden. In Anlehnung an die klassischen Schutzziele aus der IT-Sicherheit wurden folgende vier Schutzziele herausgearbeitet und auf KI übertragen.

Integrität

Integrität von KI-Modellen bedeutet, dass die Modelle “richtige” Vorhersagen auf verschiedensten eintreffenden Daten machen.

Als Beispiel kann man sich einen Spamfilter vorstellen, der auf sinnvollen Daten trainiert wurde. Dieser sollte auch noch korrekt funktionieren, d.h. Spam erkennen, auch wenn ein Angreifer eine Spam-E-Mail gezielt so verfasst, dass sie viele Elemente einer Nicht-Spam-E-Mail beinhaltet.

Verfügbarkeit

Bei der Verfügbarkeit in KI-Modellen geht es darum sicherzustellen, dass das Modell die Funktionalität erfüllt, für die es eingesetzt wird.

Nehmen wir als Beispiel nochmal den Spamfilter. Bei der Verfügbarkeit des Modells geht es weniger darum Spam zu verweigern (siehe Integrität), sondern darum sicherzustellen, dass Nicht-Spam Nachrichten durchkommen und die Nutzerin damit ihr E-Mailpostfach sinnvoll nutzen kann.

Vertraulichkeit

Vertraulichkeit beschreibt den Zustand, dass interne Eigenschaften und vertrauliche Informationen über ein trainiertes Modell den Angreifern verborgen bleiben.

Beim Spamfilter sollte es also Angreifern nicht möglich sein, herauszufinden, welche Zeichen, Wörter, oder Formatierungen dieser besonders als Indikatoren für Spam nutzt.

Privatheit

Privatheit bezieht sich im KI-Anwendungsbereich auf die Privatheit der Trainingsdaten, auf denen KI-Modelle trainiert werden. Die Modelle sollten im besten Fall keine privaten Informationen über diese preisgeben.

Bei einem Spamfilter, der auf privaten E-Mails von Alice and Bob trainiert wurde, sollen also weder sein späteres Verhalten noch seine Eigenschaften Rückschlüsse darauf zulassen, was Alice an Bob geschrieben hat.

Zuordnung von Schutzzielen und Attacken gegen KI-Modelle

Es existieren Attacken gegen KI-Anwendungen, welche gezielt die folgenden Schutzziele angreifen.

Literaturempfehlungen

Dario Amodei, Chris Olah, Jacob Steinhardt, Paul Christiano, John Schulman, and Dan Mané. Concrete Problems in AI Safety. 2016. url: https://arxiv.org/pdf/1606.06565.

Marco Barreno, Blaine Nelson, Anthony D. Joseph, and J. D. Tygar. “The security of machine learning”. In: Machine Learning 81.2 (2010), pp. 121–148. issn: 1573-0565. doi: 10.1007/s10994-010-5188-5. url: https://link.springer.com/content/pdf/10.1007/s10994-010-5188-5.pdf.

Mark Bedner and Tobias Ackermann, “Schutzziele der IT-Sicherheit” Datenschutz und Datensicherheit - DuD 34, no. 5 (May 2010): 323–28, doi: 10.1007/s11623-010-0096-1.

Luis Muñoz-González, Battista Biggio, Ambra Demontis, Andrea Paudice, Vasin Wongrassamee, Emil C. Lupu, and Fabio Roli. “Towards Poisoning of Deep Learning Algorithms with Back-gradient Optimization”. In: Proceedings of the 10th ACM Workshop on Artificial Intelligence and Security - AISec ’17. pp. 27–38. isbn: 9781450352024. doi: 10.1145/3128572.3140451.

Nicolas Papernot. A Marauder’s Map of Security and Privacy in Machine Learning.url: http://arxiv.org/pdf/1811.01134v1. 2016

Nicolas Papernot, Patrick McDaniel, Ian Goodfellow, Somesh Jha, Z. Berkay Celik, and Ananthram Swami. “Practical Black-Box Attacks against Machine Learning”. In: Proceedings of the 2017 ACM on Asia Conference on Computerand Communications Security. Ed. by Ramesh Karri. ACM, 2017. isbn: 9781450349444. doi: 10.1145/3052973.3053009.

Nicolas Papernot, Patrick McDaniel, Arunesh Sinha, and Michael P.Wellman. “SoK: Security and Privacy in Machine Learning”. In: 3rd IEEE European Symposium on Security and Privacy. Los Alamitos, California: Conference Publishing Services, IEEE Computer Society, 2018. isbn: 9781538642283. doi: 10.1109/eurosp.2018.00035.

3 - Software-Maßnahmen

Im Folgenden wird eine Auswahl an Schutzmaßnahmen vorgestellt, die die Privatsphäre oder Integrität von Machine Learning (ML) Modellen (z.B. neuronalen Netzen) erhöhen sollen.

Weil die Schutzmaßnahmen im Training angewandt werden, wird hier zuerst das Training neuronaler Netze im Allgemeinen beschrieben. Ein neuronales Netz ist eine komplexe mathematische Funktion, die durch mehrere verkettete Schichten, welche aus vielen Parametern bestehen, repräsentiert wird. Im Training lernt ein neuronales Netz mithilfe von Trainingsdaten, die Datenpunkte einer Zieldatenverteilung zu klassifizieren, indem dessen Parameter in einem iterativen Prozess verändert werden. Dabei klassifiziert das neuronale Netz die Trainingsdaten und die Klassifikationen werden durch das Netz zurück propagiert, wobei die Parameter in Richtung der korrekten Klassifikation angepasst werden. Diese Anpassung der Modellparameter wird Gradientenabstieg genannt. Wenn das Modell die Qualität seiner Klassifikationen nicht mehr verbessern kann, wird das Training beendet.

Adversarial Retraining

Adversarial Retraining ist eine Abwehrtechnik gegen sogenannte Adversarial Examples (AE). AEs sind manipulierte Inputs für neuronale Netze, welche zu einer fehlerhaften Vorhersage führen sollen. Dabei ist die Manipulation so subtil, dass sie für den menschlichen Betrachter kaum erkennbar ist. Beim Adversarial Retraining werden solche AEs mit in das Training des zu schützenden Modells aufgenommen, um dessen Robustheit und damit seine Integrität zu erhöhen.

Ein besonders beeindruckendes Beispiel von Adversarial Attacks ist die One-Pixel-Attack. Dabei wird nur ein Pixel in Bildern verändert. Häufig reicht diese kleine Veränderung aus, damit ein neuronales Netz das Bild falsch klassifiziert.

Differential Privacy

Differential Privacy (DP) ist eine populäre Metrik, mit welcher der Einfluss einzelner Daten auf das Ergebnis einer Datenverarbeitung bemessen wird. Dies entspricht gleichzeitig dem Privatsphäreverlust der Personen, zu denen die Daten gehören. Der Privatsphäreverlust wird durch das Hinzufügen von Rauschen in der Datenverarbeitung begrenzt. Ursprünglich kommt DP aus dem Bereich Datenbanken, wird aber seit einigen Jahren auch für privatsphäre-bewahrendes ML benutzt.

Der Netflix-Prize war ein im Jahr 2006 vom Streaming-Dienst Netflix ausgeschriebener Wettbewerb. Ziel war es, den besten Vorhersage-Algorithmus zu finden, welcher das Bewertungsverhalten einzelner Nutzer vorhersagen sollte. Netflix stellte Daten von über 500.000 Nutzern bereit, mit deren Hilfe die Programmierer ihre Algorithmen trainieren konnten. Zwei Wissenschaftler der University of Texas kamen auf die Idee einer sogenannten Linkage Attack. Hierfür wurden die Trainingsdatensätze von Netflix mit den Bewertungen einer anderen Bewertungsplattform namens IMDb abgeglichen. Dadurch konnten tatsächlich einige Nutzer aus den Netflix-Datensätzen identifiziert werden und es gelang eine partielle De-Anonymisierung der Daten.

Homomorphic Encryption

Homomorphic Encryption (HE) ermöglicht Rechenoperationen wie Addition oder Multiplikation auf verschlüsselten Daten. Die Ergebnisse liegen in verschlüsselter Form vor und sind nur mit Kenntnis des passenden Schlüssels einsehbar. Die Berechnungen liefern dabei die gleichen Ergebnisse, als wären sie auf unverschlüsselten Daten erfolgt.

Forscher arbeiten an praktischen Anwendungen der HE, wie z.B. der Verbesserung der Sicherheit und Transparenz von Wahlen. So könnten mithilfe des Paillier-Kryptosystems verschlüsselte Wahlstimmen automatisch - und damit korrekt - ausgezählt werden, ohne die echten Stimmen zu offenbaren. Dadurch könnte die Unverfälschtheit einer Wahl und gleichzeitig die Privatsphäre der Wähler gewährleistet werden.

Anomaly Detection

Als Anomaly Detection wird die Erkennung von Besonderheiten in Daten genannt. Durch Anwendung von Anomaly Detection können kritische Inputs wie AEs gefiltert werden, sodass die Robustheit und damit die Integrität von ML-Modellen erhöht wird.

Anomalieerkennung findet in vielen Bereichen, wie zum Beispiel der Text- und Bildverarbeitung, Betrugserkennung oder in der Medizin Anwendung.

Evaluation

Um die Schutzmaßnahmen vergleichen und deren Tauglichkeit für die Anwendung auf leistungsschwächeren Geräten wie eingebettete und Mobilgeräte bewerten zu können, wurden verschiedene ML-Experimente durchgeführt. Dabei wurden neuronale Netze auf dem MNIST- oder dem CIFAR-10-Datensatz mit je einer oder ohne Schutzmaßnahme trainiert. Der MNIST-Datensatz enthält 70.000 graustufige Bilder von handgeschriebenen Ziffern. Der CIFAR-10-Datensatz enthält 60.000 farbige Bilder von verschiedenen Tieren oder Fahrzeugen. Für den MNIST-Datensatz wurde ein Multi-Layer-Perceptron (MLP) mit etwa 670.000 Parametern verwendet, während für den CIFAR-10-Datensatz ein Convolutional-Neural-Network (CNN) mit ca. 5,8 Mio. Parametern gewählt wurde. Die Modelle wurden jeweils in 50 Epochen trainiert und anschließend für die Inferenz von 10.000 Daten benutzt. Für die Inferenz wurde immer die akkurateste Version des Modells über alle Trainingsepochen verwendet und alle 10.000 Inferenzdaten wurden einzeln klassifiziert.

Vergleich der Vorhersagequalität

Die Grafik zeigt den Verlauf der Accuracy (Vorhersagequalität) der ML-Modelle mit verschiedenen Schutzmechanismen für beide Datensätze. Auf beiden Datensätzen ist die Accuracy von Modellen, die mit Differential Privacy geschützt wurden, am schlechtesten. ML-Modelle ohne Schutzmechanismus haben über den gesamten Trainingsverlauf eine sehr ähnliche hohe Accuracy auf beiden Datensätzen. Das Adversarial Training und Retraining beeinflusst die Accuracy auf dem MNIST-Datensatz positiv, während beide auf dem CIFAR-10-Datensatz zu einer verschlechterten Accuracy führen.

Vergleich der Trainingszeit

Eingebettete und Mobilgeräte haben weniger Rechenressourcen als Desktop-PCs, Rack-Server oder Rechen-Cluster. Daher wird das Training von neuronalen Netzen meist auf letzteren durchgeführt. Dennoch ist das Training auf manchen eingebetteten Geräten wie den Jetson-Ge-räten von Nvidia möglich. Die folgende Grafik veranschaulicht die Trainingszeit von ML-Experimenten mit verschiedenen Schutzmechanismen auf zwei verschiedenen Jetson-Geräten sowie einem Desktop-PC. Die Trainingszeit ist in Sekunden auf logarithmischer Skala dargestellt. Trainings ohne Schutzmechanismus und mit Anomaly Detection benötigen etwa gleich viel Zeit, während Differential Privacy eine deutliche Verlangsamung verursacht. Adversarial Training und Retraining benötigen wiederum ein Vielfaches der Trainingszeit von Differential Privacy. Ein klarer Unterschied ist auch zwischen den verschiedenen Geräten zu erkennen. Das Jetson Nano ist wesentlich langsamer als das Jetson Xavier NX, welches seinerseits deutlich langsamer ist als der PC. Da viele Code-Bibliotheken nur sehr umständlich auf den Jetson-Geräten installiert werden können, wurden die Schutzmaßnahmen Anomaly Detection und Adversarial Training bzw. Retraining nicht angewandt.

Vergleich der Inferenzzeit

Die fertig trainierten ML-Modelle wurden auf verschiedenen Geräten ausgeführt, um einzeln alle 10.000 Testdaten eines der beiden Daten-sätze zu klassifizieren. Die durchschnittliche Inferenzzeit pro Datenpunkt ist in der folgenden Grafik für jedes Experiment in Mikrosekunden dargestellt. Für den einfacheren MNIST-Datensatz ist eine klare Ordnung von Inferenzzeiten zwischen den Geräten PC, Jetson Xavier NX, Jetson Nano, Coral Dev Board Mini und Neural Compute Stick 2 (NCS2) zu erkennen, während die Schutzmechanismen keinerlei Einfluss haben. Für den komplexeren CIFAR-10-Datensatz ist der NCS2 schneller als das Jetson Nano. Außerdem ist die Inferenzzeit für alle Schutzmechanismen auf dem gleichen Gerät etwa identisch bis auf Differential Privacy. Dies liegt an einer Modell-Schicht im CNN, die für die Anwendbarkeit von Differential Privacy von einer ähnlichen Schicht ersetzt wurde. Leider konnten keine Experimente auf dem CIFAR-10-Datensatz auf dem Coral Dev Board Mini durchgeführt werden, weil das CNN nicht für dessen Inferenz-Chip namens Edge-TPU kompiliert werden konnte.

❮ ❯

Literaturempfehlungen

Goodfellow, I. J., Shlens, J., and Szegedy, C. “Explaining and Harnessing Adversarial Examples” in ICLR (2015).

Abadi, M., Chu, A., Goodfellow, I. J., McMahan, H. B., Mironov, I., Talwar, K., and Zhang, L. “Deep Learning with Differential Privacy” in ACM CCS (2016).

Acar, A., Aksu, H., Uluagac, A. S., and Conti, M. “A Survey on Homomorphic Encryption Schemes: Theory and Implementation” in ACM CSUR (2018).

Chandola, V., Banerjee, A., and Kumar, V. “Anomaly Detection: A Survey” in ACM CSUR (2009).

4 - Hardware-Maßnahmen

Evaluierungsübersicht – Trusted Computing Verfahren

Gruppierung und allgemeine Übersicht

Die Verfahren des Trusted Computing wurden in zwei Gruppen unterteilt, die sich in der Umsetzung der Ziele des Trusted Computing unterschieden. Der Gruppe Trusted Execution Environments und verwandte Technologien sind Implementierungen zugeordnet, die dazu Technologien des vorhandenen Anwendungsprozessors nutzen. Die Gruppe Tamper Resistant Hardware hingegen bildet spezifische Hardware-Module ab, die die Ziele des Trusted Computing umsetzen bzw. deren Umsetzung ermöglichen.

Trusted Execution Environments (TEEs) und Frameworks

Basis Technologien

Die Idee eines Trusted Execution Environments (TEE) ist die Trennung sicherheitskritischer Prozesse und ihrer Daten von nicht-vertrauenswürdigem Code. Im Falle von TEEs umfasst Letzterer auch das reguläre Betriebssystem mit all seinen Prozessen (Rich Execution Environment (REE)). Das TEE hat also sein eigenes Betriebssystem und eigene Prozesse (Trusted Applications (TAs)). Um diese Trennung sicherzustellen und den Bereich des TEE auch vor den Eingriffen des REEs zu schützen, muss eine hardwarebasierte unterliegende Technologie genutzt werden. Im Folgenden werden die dafür von verschiedenen Hardwareherstellern bereitgestellten Technologien beschrieben:

TrustZone (TZ) ist eine Technologie, die auf (manchen) ARM Cortex-A Prozessoren verfügbar ist. Sie ermöglicht die Trennung von Ressourcen in eine “Secure World” und eine “Non-Secure World”. Diese Trennung wird durch bestimmte Prozessorbits und sichere Kontextwechsel umgesetzt. Die von TrustZone kontrollierten Ressourcen umfassen den Hauptspeicher, bestimmte Peripheriezugriffe und die Ausführungszeit. Wegen der hohen Verbreitung von ARM Cortex-A Prozessoren in den Bereichen der Mobilgeräte und der eingebetteten Systeme ist diese Technologie auf vielen Embedded- und Mobilgeräten verfügbar.

TrustZone-M (TZM) ist die entsprechende Technologie für ARM Cortex-M Prozessoren mit dem Unterschied, dass hierbei die Kontextwechsel mittels Branch Instructions ablaufen. Dadurch verursachen diese eine geringere Verzögerung. TrustZone-M ist optimiert für Geräte mit Low Power Profilen.

Intel SGX ist eine Instruction Set Extension, verfügbar auf einigen Intel x86 Prozessoren, zur Separation des Speichers in sogenannte “Enclaves”. Diese Enclaves werden verschlüsselt, um illegitime Zugriffe zu verhindern. Intel SGX kann mehrere sichere Bereiche in Form der Enclaves bereitstellen, kontrolliert jedoch nur den Zugriff auf deren Speicher. Eine zusätzliche Absicherung von Peripherie ist nicht vorgesehen.

AMD SEV/PSP ist die Virtualisierungstechnologie von AMD. Sie nutzt den AMD Platform Security Processor (PSP), welcher wiederum ein ARM Chip mit TrustZone ist. Der PSP ist zuständig für die Generation und Verwaltung von Schlüsselmaterial, welches für die Verschlüsselung der Speicherbereiche sowie der CPU-Register der sicheren “Guests” genutzt wird.

RISC-V Physical Memory Protection (PMP) ist ein Modul der RISC-V Architektur, mit welchem Speicherzugriff-Policies über den Prozessor umgesetzt werden können. Die Absicherung von Speicherbereichen kann bei RISC-V basierten TEEs zum Schutz der “sicheren Welten” genutzt werden.

Implementierungen

Beschrieben werden pro Lösung jeweils die notwendigen Voraussetzungen des Anwendungsprozessors bzw. des genutzten Gerätes (Plattform) und ob die Implementierung mit der GlobalPlatform TEE API Specification konform ist (GP Compliance).

Tamper Resistant Hardware (TRH)

Typen

Die verschiedenen Typen von TRH sind schwierig voneinander abzugrenzen, da kein Konsens zu herrschen scheint, wann welcher Begriff genutzt wird. Lediglich Trusted Plattform Modules (TPMs) sind durch die Trusted Computing Group (TCG) fest spezifiziert. Im Folgenden werden deshalb die Typen, wie sie in diesem Dokument genutzt werden, beschrieben. Wenn die Implementierung keiner dieser Beschreibungen entspricht, wurde in der Auflistung die Herstellerbezeichnung verwendet.

Trusted Plattform Module (TPM): Verfügt über sicheren Speicher, Funktionen zur Schlüsselgeneration und -verwaltung, einen Random Number Generator (per Spezifikation ist kein True Random Number Generator (TRNG) nötig) und Attestation-Funktionen. Spezifiziert von TCG und standardisiert in ISO/IEC 11889. TPM 1.2 und 2.0 sind die aktuell existierenden Versionen, wobei sich die beiden Varianten in Details unterschieden.

Secure Element (SE): Vor physischen Manipulationen geschütztes Modul mit eigenem Prozessor, welches Möglichkeiten zur Schlüsselgeneration und -verwaltung sowie Crypto-Primitive wie Hash-Funktionen und Verschlüsselungsfunktionen bietet. Eigener Speicher ist optional und implementierungsabhängig.

Implementierungen

Für jede TRH ist jeweils der Typ analog zur obigen Beschreibung angegeben, sowie – im Falle der Mobilgeräte – die Plattform, in welche die Lösung integriert ist. Bei “stand-alone” Produkten, die je nach Schnittstelle mit beliebigen Plattformen genutzt werden können, ist dies entsprechend vermerkt.

StrongBox Keymaster API von Android ist eine mit Android Version 9 eingeführte API, die es Anwendungsentwicklern ermöglicht sicherzugehen, dass ihr Schlüsselmaterial von einem mit den StrongBox Anforderungen (separate CPU, sicherer Speicher, ein TRNG¹, Maßnahmen gegen Manipulationen) konformen Secure Element verwaltet und gespeichert wird. Bei TRH aus dem Mobilbereich ist deshalb angegeben, ob die jeweilige Lösung mit der StrongBox API genutzt werden kann (StrongBox).

Evaluierungskriterien

Zur Evaluation einiger, für das Projekt SENSIBLE-KI vielversprechend erscheinenden Implementierungen wurden die folgenden Evaluierungskriterien festgelegt:

• Zugänglichkeit bzw. Einstiegshürden:
  Die Attraktivität für Entwickler bzw. die Wahrscheinlichkeit der tatsächlichen Nutzung der Verfahren wird durch hohe Einstiegshürden und ggf. mit dem Einsatz dieser, verbundene Kosten negativ beeinflusst.

• Funktionsumfang:
  Der tatsächliche Funktionsumfang der konkreten Verfahren ist vor allem für die spätere Zuordnung der Verfahren zu den KI-Anwendungsfällen relevant. Untersucht wurden hier z. B. welche Crypto-Funktionen umgesetzt wurden und welche Datenmengen mit dem Verfahren abgesichert werden können.

• Performance:
  Die Nutzung jedes Trusted Computing Verfahrens führt zu zusätzlichem Overhead für beispielsweise Kontextwechsel oder Datenübertragung an ein externes Modul. Um diesen Overhead besser einschätzen zu können, wurden Performance-Messungen für ausgewählte Funktionen des Verfahrens durchgeführt. Diese Ergebnisse sind für die spätere Zuordnung zu den Anwendungsfällen bzw. zur Bewertung der allgemeinen Eignung des Verfahrens wichtig.

• Marktverbreitung:
  Die Verbreitung einer Lösung hilft bei der Bewertung der Relevanz in der Wirtschaft und wird deshalb – falls möglich – erfasst.

Evaluierte Verfahren - Mobilgeräte

Begründung der Auswahl

Mit Apple und Samsung decken wir zwei der größten Gerätehersteller weltweit ab. Da sich zwischen iOS- und Android-Geräten sowohl Software als auch Hardware stark unterscheiden, ist diese Gegenüberstellung unverzichtbar.

Android-Geräte machen 70% des Smartphone-Marktes aus. Deshalb wurden stellvertretend verschiedene Pixel-Geräte vom Hersteller Google evaluiert, da dort eine optimierte und unveränderte Android Implementierung zur Verfügung steht, welche keine zusätzlichen Hersteller-Apps (sog. Bloatware) enthält.

Von jedem Hersteller wurden High-End Geräte gewählt, da diese jeweils über alle wichtigen, durch den Hersteller zum Zeitpunkt der Evaluierung bereitgestellten, Funktionen verfügen.

Anmerkung zur Performance-Messung

Als Input für die symmetrischen Crypto-Funktionen wurden jeweils Blöcke zufälliger Daten mit einer Größe von 8 MB verwendet.

Da die API für die iOS Secure Enclave nur die Verwendung von asymmetrischer Kryptografie erlaubt , wurde die Performance von AES-Algorithmen via ECIES-Entschlüsselung mit einem secp256r1 –Schlüssel (für AES-128-GCM) bzw. einem secp521r1-Schlüssel (für AES-256-GCM) aus der SE erhoben. Dabei ist zu bemerken, dass die Performance von AES-GCM via ECIES unter iOS nicht mit der Performance von AES-GCM unter Android verglichen werden sollte: beim ECIES-Verfahren wird der in der Hardware gespeicherte Schlüssel nur für die initiale Schlüsselableitung benötigt.

Evaluierungen

Übersicht der Ergebnisse

Tabelle 12: Übersicht der Ergebnisse für Mobilgeräte

Evaluierte Verfahren – Eingebettete Systeme

Begründung der Auswahl

Als TEE wurde OP-TEE gewählt, da es sich um eine Opensource-Lösung handelt und somit eine der wenigen, auf die problemloser Zugriff möglich ist. Außerdem ist OP-TEE kompatibel mit der GlobalPlatform (GP) TEE API und dementsprechend geeignet für Entwicklung von TAs für alle GP kompatiblen TEEs.

Kinibi-M auf dem SAML11 Evaluation Kit wurde gewählt, um Arm-Cortex M Prozessoren mit TrustZone-M Unterstützung abzudecken.

Der NXP SE050 und der Zymkey 4i von Zymbit sind beide Secure Elements, kompatibel mit dem RasperryPi und somit leicht zu evaluieren und gut für die Entwicklung von Prototypen einzusetzen. Die SEs unterschieden sich in den verfügbaren Crypto-Funktionen und der Zielgruppe. Zudem wurde als TRH das TPM 2.0 Modul von Let’sTrust gewählt. Dieses ist ebenfalls kompatibel mit dem RaspberryPi und implementiert die TPM 2.0 Spezifikation.

Anmerkung zur Performance-Messung

Als Inputgröße für die Crypto-Funktionen wurde jeweils entweder die maximal unterstützte Buffergröße oder, bei keiner offenkundigen Begrenzung, 1MB verwendet. Es wurde jeweils der letzte API-Call vor einem Wechsel in entweder die Schnittstellenübertragung zur TRH bei externen Modulen oder einem Kontextwechsel in die sichere Welt bei TEEs gemessen.

Übersicht der Ergebnisse

Tabelle 17: Übersicht der Ergebnisse für eingebettete Systeme

5 - Evaluierung

Software- und Hardware-seitige Schutzmaßnahmen können anhand verschiedener Kriterien bewertet werden. Wichtige Kriterien sind

• Genauigkeit (Anteil korrekter Vorhersagen auf Testdaten)
• Robustheit (Genauigkeit auf manipulierten Daten)
• Privatsphärerisiko (Wirksamkeit von Membership-Inference-Attacken)
• Trainingszeit (Dauer des Modelltrainingsprozesses)

Für eine sinnvolle Interpretation der Bewertung sollte diese mit der Bewertung derselben KI-Anwendung ohne Schutzmaßnahme verglichen werden.

Im folgenden werden die Evaluationsergebnisse einiger Schutzmaßnahmen für beispielhafte KI-Anwendungen dargestellt.

Software-Maßnahmen

Die Robustheit beschreibt das Verhältnis der Genauigkeit mit normalen Eingangsdaten zu der Genauigkeit mit bösartig manipulierten (adversarial) Eingangsdaten.

Das Privatsphärerisiko wird berechnet als der Vorteil eines Angreifers mit Membership-Inference-Angriffen (True Positive Rate / False Positive Rate - 1).

MNIST-Datensatz

CIFAR10-Datensatz

Hardware-Maßnahmen

6 - Empfehlungen

Schutzmaßnahmen der Prototypen und Anwendungsszenarien

1. Einleitung

Im Folgenden werden softwarebasierte Schutzmaßnahmen sowie Verfahren aus dem Bereich des Trusted Computing vorgeschlagen, um den Schutz vor Angriffen auf KI-Anwendungen auf mobilen und eingebetteten Geräten zu verbessern.

Zu Beginn werden in Kapitel 2. Betrachtete Maßnahmen alle in diesem Dokument betrachteten Maßnahmen mit ihrer jeweiligen Schutzwirkung in einer Übersicht vorgestellt. Im darauffolgenden Kapitel 3. Schutzmaßnahmen nach Anwendungs-Charakteristiken werden diese Schutzmaßnahmen zunächst generisch für Anwendungen mit spezifischen Anwendungscharakteristiken vorgeschlagen. Danach werden auf Basis dieser generischen Vorschläge Schutzkonzepte für zwei konkrete Anwendungen, die im Rahmen des Projektes SENSIBLE-KI entwickelt werden – “SeamlessMe” und “Self-ID” – in Kapitel 4. Referenzarchitekturen vorgestellt.

Die vorgeschlagenen Maßnahmen und Schutzkonzepte sind jeweils zusätzlich zu Verfahren der allgemeinen System- und Anwendungssicherheit (bspw. TLS-Verschlüsselung bei Netzwerkkommuni-kation) zu betrachten, welche nicht im Scope dieses Verbundvorhabens liegen.

2. Betrachtete Maßnahmen

Die hier betrachteten Maßnahmen sind entweder dem Bereich softwarebasierter Schutzmaßnahmen oder den Trusted-Computing-Verfahren zuzuordnen. In diesem Abschnitt werden zur Übersicht alle betrachteten Maßnahmen zusammen mit der erzielten Schutzwirkung und anderen nennenswerten Effekten aufgelistet.

2.1 Softwarebasierte Maßnahmen

2.2 Trusted Computing

3. Schutzmaßnahmen nach Anwendungs-Charakteristiken

Im Folgenden werden die Anwendungsszenarien anhand der Architekturmerkmale der KI-Systeme in zwei abstrakte Gruppen unterschieden: netzwerkbasierte Anwendungen (wie P2P-Netzwerke oder die klassische Server-Client-Architektur) und End-Node-Only-Anwendungen – also Architekturen, die auf ein Endgerät begrenzt sind. Bei netzwerkbasierten Architekturen ist ein regelmäßiger Austausch von Daten oder (im Falle von OTA-Updates) des Modells selbst über ein Netzwerk erforderlich. End-Node-Only-Architekturen sind hingegen auf ein Endgerät begrenzt und der Austausch mit einem anderen Gerät beschränkt sich maximal auf Informationen, die nicht mit dem KI-Anteil der Anwendung in Verbindung stehen.

Da sich die zwei Architekturtypen hauptsächlich in der Notwendigkeit des Austauschs über das Netzwerk unterscheiden, werden generelle Maßnahmen für KI-Anwendungen mit bestimmten Charakteristiken im Allgemeinen und zusätzliche für netzwerkbasierte Architekturen empfohlen. Für eine spezifische Anwendung kann dann anhand der Charakteristiken die Schnittmenge aller vorgeschlagenen Schutzmaßnahmen für die Anwendung bestimmt werden.

Dabei ist zu beachten, dass softwarebasierte Schutzmaßnahmen für Privatheit und Robustheit sich gegenseitig negativ beeinflussen. Das heißt, dass softwarebasierter Privatheitsschutz die Robustheit beeinträchtigt und umgekehrt softwarebasierter Robustheitsschutz sich negativ auf die Privatheit auswirkt. Daher muss im Einzelfall abgewogen werden, welches Schutzziel wichtiger ist bzw. ob eine ausreichende Schutzwirkung mit ausschließlich hardwarebasierten Maßnahmen erreicht werden kann. Weiterhin sind alle Schutzmaßnahmen, die die Ausführung des eigenen Codes innerhalb eines Trusted Execution Environments (TEE) erfordern, zurzeit für mobile Anwendungen nicht umsetzbar. Diese Beschränkung liegt daran, dass jegliche Applikationen, die im TEE ausgeführt werden sollen, zusammen mit dessen Code kompiliert werden müssen. Es ist deshalb zum heutigen Zeitpunkt wenigen, meist nur den herstellereigenen System-Apps möglich, Code im TEE des Mobilgerätes eines Nutzers auszuführen.

3.1 Maßnahmen nach Quelle der Inputdaten:

Bei der Nutzung eigener, vertrauenswürdiger Inputdaten wird zur Verbesserung der Robustheit und der allgemeinen Accuracy die Durchführung von Data Sanitization empfohlen, um fehlerhafte oder unvollständige Daten zu bereinigen oder zu entfernen und alle Daten in die passende Form zu bringen, z. B. durch Normalisieren.

Im Falle nicht vertrauenswürdiger Inputdatenquellen sollte zusätzlich Adversarial Training eingesetzt werden, um die Robustheit des Systems zu stärken. Außerdem sollten mittels Anomaly Detection manipulierte Trainings- und Inferenzdaten zum Schutz vor Data Poisoning bzw. Adversarial Attacks erkannt und entfernt werden, falls die zusätzlich benötigten Ressourcen zur Verfügung stehen. Dies gilt insbesondere für Systeme mit deutlichem Schadenspotential, ist aber in jedem Fall wünschenswert.

Bei Nutzung externer Sensordaten auf einem System mit deutlichem Schadenspotential, die über ein nicht vertrauenswürdiges Medium (z. B. aber nicht ausschließlich das Netzwerk) übertragen werden, kann durch ein Secure Element (SE) eine Attestierung der Sensordaten – direkt beim Auslesen des Sensors – durchgeführt werden. Zusätzlich sollten Angriffe über die Inputdaten, wie eingangs beschrieben, durch Adversarial Training und Anomaly Detection abgefangen werden.

3.2 Maßnahmen nach Personenbezug und Vertraulichkeit

Werden personenbezogene Daten oder sensible Daten im Allgemeinen verarbeitet, sollte die Privatheit des Modells gestärkt werden. Dies ist z. B. möglich durch den Einsatz von Differential Privacy während des Trainings und Data Sanitization der sensiblen Output-Daten.

Bei deutlichem Schadenspotential und/oder direktem Personenbezug der Daten und/oder hoher Vertraulichkeit des Modells sollte die Ausführung der Inferenz innerhalb eines Trusted Execution Environments (TEE) in Erwägung gezogen werden. Die konkrete Umsetzung dieser Schutzmaßnahme ist jedoch mitunter – je nach Ansatz – mit einigen nachteiligen Effekten (wie erhöhten Latenzen, Strom- und Speicherverbrauch) und technischen Hürden verbunden. Außerdem muss darauf geachtet werden, dass die zu schützenden Daten nie unverschlüsselt das TEE verlassen. Lässt sich dies nicht verhindern, ist die Maßnahme nicht mehr zum Schutz der Privatheit und lediglich zur Erhöhung der Robustheit und zum Schutz der Vertraulichkeit des Modells bei Ausführung auf dem Endgerät geeignet.

3.3 Spezifische Maßnahmen für netzwerkbasierte Architekturen

Bei einer Server-Client-Architektur oder anderen netzwerkbasierten Architekturen werden Daten und/oder Modellupdates über das Internet übertragen. Bei dieser Architekturform ist es deshalb – je nach Schutzbedarf – ratsam, zusätzlich zur allgemeinen Anwendungssicherheit, Maßnahmen gegen Manipulationen auf dem Übertragungsweg zu treffen. Alle hier genannten Maßnahmen können generell auch ohne den Einsatz von Trusted Computing umgesetzt werden – sind dadurch jedoch angreifbarer, verursachen allerdings auch geringere Latenzen. Es ist also nach der Auswahl der Maßnahmen noch einmal abzuwägen, wann eine Nutzung von Trusted Computing zur Umsetzung dieser sinnvoll und angemessen ist. Weiterhin ist zu beachten, dass im Falle von P2P-Netzwerkarchitekturen die Verteilung der Schlüssel beispielsweise für Signaturen unter Umständen komplexer sein kann als bei einer Client-Server-Architektur. Grundsätzlich muss bei P2P-Architekturen mehr Geräten vertraut werden als bei einer zentralisierten Architektur. So muss z. B. im Fall der Geräteattestierung nicht nur einem Gerät (dem Server) die Anfrage auf Attestierung ermöglicht werden, sondern mehreren anderen Knoten. Dies muss beim Erstellen des Schutzkonzeptes einer solchen Anwendung beachtet werden.

Bei deutlichem Schadenspotential des Systems kann durch eine Geräteattestierung des Endgerätes mittels TEE dessen Softwareintegrität gegenüber dem Empfänger (üblicherweise dem Server) verifiziert werden. Ebenso können die Daten mit einer Attestierung versehen werden, die z. B. angibt, dass die Daten von der aktuellen Version des Modells erzeugt wurden, was die Robustheit des Systems stärkt.

Bei Modellupdates über das Netzwerk sollte durch Signatur des Modells sichergestellt werden, dass der Empfänger das korrekte Modell erhalten hat. Die Signatur wird vom Sender erstellt und auf dem Endgerät vor der Ausführung geprüft. Diese Maßnahme sollte in jedem Fall im Rahmen der allgemeinen Anwendungssicherheit umgesetzt werden, aber besonders bei deutlichem Schadenspotenzial ist die Durchführung der Attestierung und Signatur mittels Trusted Computing sinnvoll.

Bei Personenbezug der zu übertragenden Daten ist eine Verschlüsselung dieser bei Übertragung unerlässlich. Je nach Sensibilität der Daten kann z. B. die reguläre TLS-Verschlüsselung durch Einbinden eines Secure Elements (SE) gestärkt werden.

4. Referenzarchitekturen

4.1 SeamlessMe

Architekturbeschreibung
Der im Demonstrator “SeamlessMe” eingesetzte Machine-Learning-Algorithmus ist eine Einzelklassen-Klassifizierung (One Class Classification), die durch eine Ausreißererkennungsmethodik (Novelty Detection) erweitert wird. Ein generischer Klassifikator (Generic Classifier) wird auf das mobile Endgerät geladen. Daraufhin lernt das Modell lokal anhand der auf dem Gerät gesammelten Benutzerdaten (User Specific Classifier). Das trainierte Modell wird dann verwendet, um ein Trust Level (Konfidenzwert) zu generieren. Die Berechnung des Vertrauensniveaus des Benutzers erfolgt lokal auf dem Smartphone und ohne Kommunikation mit einem externen Server. Sowohl das Training als auch die Inferenz finden also direkt auf dem Endgerät statt.

“SeamlessMe” wird hauptsächlich auf Smartphones implementiert. Während der Forschungs- und Entwicklungsphase sind ebenfalls verschiedene Wearables, wie beispielsweise Smartwatches, getestet worden. Allerdings haben diese Geräte derzeit eine geringere Funktionalität und sind daher noch nicht für die Anwendung geeignet.

Die von “SeamlessMe” verarbeiteten biometrischen Daten sind äußerst sensibel, da sie zur direkten Identifizierung von Personen verwendet werden können. Im medizinischen Kontext können Gangprofile beispielsweise als Indikatoren für bestimmte Krankheiten genutzt werden, was die Sensibilität dieser Daten zusätzlich erhöht. Die Modellarchitektur muss jedoch nicht geschützt werden, da sie bereits öffentlich bekannt ist.

Vorgeschlagene Maßnahmen
Auf Basis der in Kapitel 3. Schutzmaßnahmen nach Anwendungs-Charakteristiken ausgeführten Zuordnungen der Schutzmaßnahmen zu charakteristischen Eigenschaften der Anwendung sind folgende Schutzmaßnahmen umzusetzen:

Der Personenbezug der verarbeiteten biometrischen Daten führt zu einem erhöhten Privacy-Schutzbedarf der Anwendung. Da es sich um eine mobile Anwendung handelt, ist jedoch der Einsatz eigener Trusted Applications nicht möglich und somit auch die Ausführung in einem TEE keine Option. Generell ist auf Mobilgeräten der Zugriff auf im Gerät vorhandene Trusted-Computing-Lösungen (TEE/SE) auf die durch die Android-API angebotenen Funktionen beschränkt. Daher kann zur Verbesserung der Privatheit der Anwendung nur die Nutzung des Hardware-backed Keystores oder der StrongBox bzw. der Schlüsselverwaltung der Secure Enclave unter iOS zur Sicherung der erhobenen Daten umgesetzt werden. Der Einsatz von Differential Privacy bietet sich hier nicht an, da daraus ein zu hoher Verlust an Vorhersagequalität resultieren würde. Dies liegt daran, dass die Trainingsdaten alle von derselben Person stammen und daher ein viel stärkeres Verrauschen für praktischen Privatheitsschutz nötig wäre als üblich.

Da das Training unbeaufsichtigt auf dem Mobilgerät und somit mit nicht vertrauenswürdigen Daten durchgeführt wird, wird Anomaly Detection auf den Input-Daten eingesetzt, um die Robustheit des Modells zu erhöhen. SeamlessMe nutzt das Vorgehen der Anomaly Detection bereits im Rahmen des Authentifizierungsalgorithmus. Die Anwendung soll Laufsequenzen erkennen, die nicht mit den zuvor trainierten Samples übereinstimmen. Ist dies der Fall, gilt die Person nicht als authentifiziert. Ebenfalls werden die zu dem Zeitpunkt aufgenommenen Daten nicht zum Training des Modells verwendet und stellen somit keine Gefahr mehr für das Modell dar.

Zudem wird Data Sanitization der Input-Daten durchgeführt, um unbrauchbare Daten zu entfernen. Die Anwendung setzt auch diese Maßnahme bereits implizit um, da nur Daten, die dem Laufmuster eines Menschen entsprechen, für die Gang-Authentifizierung – und somit mit dem Modell – verwendet werden.

Adversarial Training ist für diese Anwendung nicht geeignet, da es davon ausgegangen wird, dass Angreifer keine Sensordaten innerhalb des Endgeräts manipulieren können. Wenn sie es doch könnten, würde das implizieren, dass sie die gesamte KI-Anwendung kompromittieren könnten, was wiederum die Manipulation der Sensordaten aus Sicht der Angreifer unnötig machen würde. Stattdessen wird angenommen, dass Angreifer nur analoge Inputdaten verändern können, indem sie sich mittels des Smartphones einer zugriffsberechtigten Person für diejenige Person ausgeben, d. h. deren Gangprofil nachahmen. Damit ein solcher analoger Angriff abgewehrt werden kann, muss eine hohe allgemeine Vorhersagequalität der Anwendung gewährleistet werden.

4.2 Self-ID

Architekturbeschreibung
Bei der Demonstrator-Anwendung “Self-ID" wird ein binärer Klassifikator (Selbstbild vs. Fremdbild) auf einer Population angelernt. Dieser Klassifikator lernt anhand von Eye-Tracking-Daten zu unterscheiden, welche Klasse von Gesichtsbildern der Nutzer gerade sieht. Der Trainingsprozess findet im Vorfeld – offline – und anhand von zuvor gesammelten Trainingsdaten statt. Sollte ein persönliches Enrollment notwendig sein, wird dieses auf dem Endgerät stattfinden und das angelernte Modell wird anschließend an den Server übertragen. Die Inferenz findet online auf dem Server statt. Die Eye-Tracking-Daten werden dabei vom Client an den Server übertragen. Dieser wertet das Ergebnis aus und leitet ggf. entsprechende Maßnahmen ein.

In der ersten Ausbaustufe wird der Zugänglichkeit halber ein Desktop-Client per Plugin oder Erweiterung eines bestehenden Videokonferenzsystems genutzt. Dieser Desktop-Prototyp dient dazu, erste Erfahrun-gen mit der Technologie zu sammeln. In einer späteren Ausbaustufe soll auch eine mobile Anwendung auf Smartphones (Android und iOS) umgesetzt werden. Auf diesen Plattformen ist allerdings nach aktuellem Stand der Technik die Eye-Tracking-Technologie noch nicht in ausreichender Qualität verfügbar.

Die Eye-Tracker-Daten enthalten biometrische Informationen und dienen der Validierung der Identität des Nutzers. Daher sind diese Daten sensibel und fallen unter die Datenschutz-Grundverordnung (DSGVO), da es sich um eine Art personenbeziehbarer Daten handelt. Zudem können die Daten auch medizinische Implikationen, z. B. Hinweise auf Krankheitssymptome, beinhalten. Das Modell gewährleistet die Sicherheit des Videokonferenzsystems und hat dementsprechend – je nach Vertraulichkeit der Gesprächsinhalte – erhöhte Robustheitsanforderungen. Im Zielsystem kann durch Manipulation des Modells oder der Inferenz-Daten ein Angriff auf die Erreichbarkeit von Video-Konferenzen (Erzeugen von False-Positives) oder ein erfolgreicher Identitätsdiebstahl (Erzeugen von False-Negatives) durchgeführt werden. Außerdem kann das Modell zweckendfremdet werden, um Personen in Systemen zu identifizieren, wo dies gemäß der Zweckbindung nicht zulässig ist. Das Modell lässt möglicherweise Rückschlüsse auf die biometrischen Daten, mit denen es angelernt wurde, zu. Im fertigen Produkt ist das Modell, welches mit internen Daten angelernt werden wird, geistiges Eigentum der Bundesdruckerei und sollte somit vertraulich bleiben.

Vorgeschlagene Maßnahmen
Auf Basis der in Kapitel 3. Schutzmaßnahmen nach Anwendungs-Charakteristiken ausgeführten Zuordnungen der Schutzmaßnahmen zu charakteristischen Eigenschaften der Anwendung werden folgende Schutzmaßnahmen umgesetzt:

Die zu erzielende Vertraulichkeit des Modells kann zur Zeit des Enrollments auf dem Endgerät nur über Verfahren der allgemeinen Anwendungssicherheit (bspw. Obfuscation) gestärkt werden, da weder auf Desktop- noch auf Mobilgeräten der dafür notwendige Zugriff auf ein TEE möglich ist. Die Vertraulichkeit des Modells auf dem Server wird durch Maßnahmen der allgemeinen Systemsicherheit oder verfügbaren serverseitigen Trusted-Computing-Verfahren sichergestellt. Die Betrachtung dieser Maßnahmen liegt außerhalb des Scopes dieses Dokuments.

Für die angestrebte Implementierung auf Mobilgeräten soll zum Schutz der Privatheit der personen-bezogenen Daten der Hardware-backed Keystore oder die StrongBox bzw. die Secure Enclave zur Sicherung etwaiger auf dem Endgerät abgelegter Daten und – falls anwendbar – für die Verschlüsselung der Daten vor der Übertragung an den Server, genutzt werden. Im Falle des Desktop-Prototypen wird an Stelle dessen die Nutzung der verfügbaren Verschlüsselungsfunktionen des Gerätes/Betriebssystems empfohlen.

Je komplexer der Output eines ML-Modells ist, desto effektiver können Privatsphäre-Angriffe auf die Trainingsdaten des Modells sein (vgl. Shokri et al.: “Membership Inference Attacks Against Machine Learning Models”, IEEE Symposium on Security and Privacy, 2017). Daher sollten die personenbezogenen Daten der Anwendung zusätzlich durch Data Sanitization der Output-Daten geschützt werden, falls der genutzte Klassifikator nicht nur die Klasse, sondern auch die Konfidenz ausgibt. Weiterhin kann Differential Privacy beim Training des Klassifikators angewandt werden, um Informationen einzelner Trainingsdaten zu verschleiern.

Die durch das erhöhte Schadenspotenzial erforderliche Robustheit der Anwendung gegenüber manipulierten Inputdaten soll im Rahmen der allgemeinen Systemsicherheit durch eine Client-Authentication verbessert werden. Diese kann im mobilen Client durch die Nutzung des Hardware-backed Keystores oder der StrongBox verstärkt werden. Weiterhin ist der Einsatz von Anomaly Detection und Adversarial Training erforderlich, da nicht sichergestellt werden kann, dass keine manipulierten Inputdaten verarbeitet werden. Anomaly Detection wird dabei genutzt, um manipulierte Inputdaten zu erkennen und herauszufiltern bevor das Modell sie verarbeitet. Adversarial Training erhöht die Robustheit des Modells gegen manipulierte Inputdaten.

Heutige Methoden zum Schutz der Privatheit verschlechtern gleichzeitig die Robustheit. Dies gilt umgekehrt genauso. Außerdem verschlechtern Methoden zum Schutz der Privatheit und Robustheit jeweils meist die Vorhersagequalität des Modells. Daher muss hier vorsichtig abgewogen werden, wie viel Privatheit, Robustheit und allgemeine Vorhersagequalität akzeptabel sind. Für diese Anwendung scheint es am besten zu sein, zugunsten von Robustheit auf Schutz der Privatheit innerhalb des Modells zu verzichten. Da das Modell selbst nicht auf einem Endgerät ausgeführt wird, sind nur Black-Box Angriffe auf die Privatheit möglich, welche deutlich schwächer als White-Box-Angriffe sind. Daher werden hier zugunsten des softwareseitigen Robustheitsschutzes keine weiteren Maßnahmen zum Schutz der Privatheit vorgeschlagen. Dabei wird davon ausgegangen, dass es Angreifern durch Maßnahmen der allgemeinen Systemsicherheit erschwert wird, sich Zugang zum Modell auf dem Server zu verschaffen.

5. Fazit

In diesem Dokument wurden ausgewählte Maßnahmen, die im Verbundvorhaben SENSIBLE-KI evaluiert wurden, für generelle Anwendungsfälle und für zwei spezifische Anwendungen – die im Projekt zu entwickelnden Prototypen – vorgeschlagen. Je konkreter der Anwendungsfall, desto mehr wurde die Auswahl der sinnvoll einzusetzenden Maßnahmen eingegrenzt, da sowohl die Praktikabilität in der spezifischen Anwendung als auch die Wechselwirkung zwischen verschiedenen Maßnahmen mit unterschiedlicher Schutzwirkung zu beachten sind. Besonders die hardwarebasierten Trusted-Computing-Verfahren können bei den Schutzkonzepten der Prototypen nur in geringem Maße eingesetzt werden, da der Zugriff auf diese bei mobilen Anwendungen stark beschränkt ist. Die softwarebasierten Maßnahmen erfahren keine solche Einschränkung, sind jedoch mehr von negativen Wechselwirkungen betroffen, sodass der Einsatz zweier sich negativ beeinflussender Verfahren im Einzelfall gegeneinander abgewogen werden muss.

7 - Best Practices

Beschreibung der Schutzziele

Dieses Kapitel enthält eine kurze Beschreibung der im späteren Verlauf thematisierten Schutzziele

Robustheit

Die Robustheit eines Modells setzt sich zusammen aus der Integrität und der Verfügbarkeit des Modells. Dabei beschreibt die Integrität die Fähigkeit des Modells, korrekte Vorhersagen zu treffen. Diese kann durch Beeinflussung der Modell-Inputs, -Outputs sowie -Parameter beeinträchtigt werden. Die Verfügbarkeit von KI-Modellen ist die Sicherstellung der Funktion. Wenn ein Angreifer auf die Verfügbarkeit des Modells abzielt, veranlasst er das System dazu, gutartige Instanzen zu verweigern und dadurch nicht richtig zu arbeiten. Wenn die Ausgabe des ML-Modells in die Funktion des Systems eingebunden ist, kann dies als Denial-of-Service-Angriff betrachtet werden.

Privatheit

Die Privatheit bezieht sich im KI-Anwendungsbereich auf die Geheimhaltung der Trainingsdaten, auf denen KI-Modelle trainiert werden. Ein Angriff auf die Privatheit des Modells kann schwerwiegende Auswirkungen auf die Privatsphäre der betroffenen Personen haben. Im schlimmsten Fall können zum Training verwendete Daten vollständig rekonstruiert werden.

Ein wichtiger Aspekt im Bereich der Privatheit ist die Anonymität in Abgrenzung zur Pseudonymität. Anonymität kann als der Schutz vor Identifizierung im Allgemeinen und Pseudonymität als der Schutz vor namentlicher Identifizierung definiert werden. Dies impliziert, dass bspw. zum Erreichen der Anonymität zwei Bilder nicht einander zugeordnet werden dürfen. Speziell während des Trainings von KI-gestützter Identifikation im Bereich der Biometrie kann die Anonymität nicht gewährleistet werden. Hier ist das schwächere Schutzziel der Pseudonymität zu verfolgen. Verglichen mit Anonymität hat Pseudonymität den Nachteil, dass diese ggf. durch Verbindung mehrerer Datenbanken mittels sog. Linkage Attacks umgangen werden kann.

Vetraulichkeit

Bei der Vertraulichkeit eines KI-Systems geht es darum, dass interne Eigenschaften und vertrauliche Informationen über ein trainiertes Modell potenziellen Angreifern verborgen bleiben.

Ein Angriff auf die Vertraulichkeit kann es einem Angreifer ermöglichen, sensible und vertrauliche Informationen über das trainierte ML-Modell, seine Eigenschaften, Struktur und Parameter zu erlangen. Dadurch könnte der Angreifer in der Lage sein, das im Modell repräsentierte geistige Eigentum zu stehlen, gezielter zu manipulieren oder auch – basierend auf dem gewonnenen Wissen – die Privatheit der Trainingsdaten anzugreifen.

Beschreibung der Demonstratoren

Innerhalb des Forschungsprojekt wurden zwei Demonstratoren entwickelt. Der Demonstrator SeamlessMe ermöglicht die Authentifizierung anhand menschlicher Gangprofile. Der Demonstrator Self-ID ermöglicht die Bestätigung der eigenen Identität mithilfe von Eyetracker-Daten. Für diese KI-Anwendungen wurde der Schutzbedarf bestimmt und die für sie vorgeschlagenen Maßnahmen und Schutzkonzepte exemplarisch implementiert sowie evaluiert. Im Folgenden werden beide Anwendungen näher beschrieben.

Gang-Authentifizierung (SeamlessMe)

Der im Demonstrator “SeamlessMe” eingesetzte Machine-Learning-Algorithmus ist eine Einzelklassen-Klassifizierung (One Class Classification), die durch eine Ausreißererkennungs-Methodik (Novelty Detection) erweitert wird. Ein generischer Klassifikator (Generic Classifier) wird auf das mobile Endgerät geladen. Daraufhin lernt das Modell lokal anhand der auf dem Gerät gesammelten Benutzerdaten (User Specific Classifier). Das trainierte Modell wird dann verwendet, um ein Trust Level (Konfidenzwert) zu generieren. Die Berechnung des Vertrauensniveaus des Benutzers erfolgt lokal auf dem Smartphone und ohne Kommunikation mit einem externen Server. Sowohl das Training als auch die Inferenz finden also direkt auf dem Endgerät statt.

Selbstvalidierung (Self-ID)

Bei der Demonstrator-Anwendung “Self-ID" wird ein binärer Klassifikator (Selbstbild vs. Fremdbild) auf einer Population angelernt. Dieser Klassifikator lernt anhand von Eye-Tracking-Daten zu unterscheiden, welche Klasse von Gesichtsbildern der Nutzer gerade sieht. Der Trainingsprozess findet im Vorfeld – offline – und anhand von zuvor gesammelten Trainingsdaten statt. Sollte ein persönliches Enrollment notwendig sein, wird dieses auf dem Endgerät stattfinden und das angelernte Modell wird anschließend an den Server übertragen. Die Inferenz findet online auf dem Server statt. Die Eye-Tracking-Daten werden dabei vom Client an den Server übertragen. Dieser wertet das Ergebnis aus und leitet ggf. entsprechende Maßnahmen ein.

Maßnahmen

Adversarial Training

Adversarial Retraining ist eine Schutzmaßnahme zur Stärkung der Robustheit eines Machine Learning Modells und eine Abwehrtechnik gegen sogenannte Adversarial Examples (AE). AEs sind manipulierte Inputs für neuronale Netze, welche zu einer fehlerhaften Vorhersage führen sollen. Dabei ist die Manipulation so subtil, dass sie für den menschlichen Betrachter kaum erkennbar ist. Beim Adversarial Retraining werden solche AEs mit in das Training des zu schützenden Modells aufgenommen, um dessen Integrität zu erhöhen.

Szenario

Das Testen der vorgeschlagenen Sicherheitsmaßnahme geschah anhand des Self-ID-Demonstrators.

Im gewählten Angriffsszenario haben subtile Änderungen an den Eingabedaten für das Modell zu fehlerhaften Ausgaben geführt. Damit wurde die Zuverlässigkeit und Vertrauenswürdigkeit des maschinellen Lernsystems verringert. Neuronale Netze wurden nicht verwendet.

Die gezielte Manipulation von Eingabedaten durch einen “internen Angreifer” wurde durchgeführt. Auf komplexere Evasionsangriffe, wie beispielsweise das Generieren von AEs durch Generative Adversarial Networks (GANs), wurde verzichtet. Für das Beispiel musste zuerst eine ausreichend starke Verzerrung gefunden werden, sodass eine falsche Vorhersage entstand.

Das konzipierte Angriffsszenario hatte verschiedene Voraussetzungen: Zugriff auf die Eingabedaten

Im gewählten Beispiel waren die Art und der genaue Aufbau der Eingabedaten bekannt, sodass eine verhältnismäßige simple Verschiebung der Daten als Manipulation dienen konnte.

Einsicht der Vorhersagen

Für das Beispiel wurde aufgezeichnet, ab welchem Grad der Veränderung der Eingabedaten ein anderes Label vorhersagt wurde. Innerhalb der Testumgebung konnte somit nachvollzogen werden, wenn die Werte einen Schwellwert überschritten haben.

Beliebige Anzahl an Vorhersagen

In der Testumgebung konnte eine beliebige Anzahl an Vorhersagen vorgenommen werden.

Erfahrungswerte

Im gewählten Beispiel wurde ein „interner“ Angreifer simuliert, welcher Zugriff auf das gesamte Projekt und die Ergebnisse der Klassifizierung hatte. Ohne das Wissen über die Auswirkungen der AEs hätten diese nicht vorhersehbar das Vorhersageergebnis verändert. Des Weiteren ist Wissen über die verwendeten Merkmale nötig, welche dem Angreifer nicht zwangsläufig zur Verfügung stehen.

Der Erfahrungswert war, dass eine Änderung ohne ausreichendes Wissen nicht zum gewünschten Ergebnis führen kann. Je nach Systemarchitektur kann der Angreifer nicht nachvollziehen, ob seine AEs tatsächlich eine Änderung bei der Vorhersage ausgelöst haben.

Implementierungshilfe

“Tipps & Tricks”

Eine Vielzahl an Beispielen und Implementierungsmöglichkeit finden sich in folgender Bibliothek: Adversarial Robustness Toolbox¹

Code-Snippets Eingabedaten verfälschen

    perturbation_sample = sample_array + perturbation_strength

Auswirkungen betrachten und Vorhersagen vergleichen

    original_prediction = classifier.predict(original_sample_df)
    perturbed_prediction = classifier.predict(perturbation_sample)

Anomaly Detection

Anomaly Detection wird zur Stärkung der Robustheit eines Machine Learning Systems eingesetzt. Durch Anwendung von Anomaly Detection können kritische Inputs (wie z. B. AEs) gefiltert werden, um ungewöhnlich stark abweichende Daten-Inputs zu entfernen, die die Integrität des Modells beeinträchtigen könnten.

Szenario

Das Testen der vorgeschlagenen Sicherheitsmaßnahme geschah anhand des SeamlessMe-Demonstrators. Das Ziel besteht darin, eine möglichst kleine Grenze zu finden, die die normalen Datenpunkte umgibt, während gleichzeitig Ausreißer außerhalb dieser Grenze liegen. SeamlessMe nutzt das Vorgehen der Anomaly Detection bereits indirekt als Authentifizierungsalgorithmus:

Es geht darum Laufsequenzen zu erkennen, die nicht mit den zuvor trainierten Samples übereinstimmen. Ist dies der Fall, gilt die Person nicht als authentifiziert. Ebenfalls werden die zu dem Zeitpunkt (nicht-authentifiziert) aufgenommenen Daten nicht zum Training des Models verwendet. Nur wenn der Algorithmus sich sicher ist, dass die Daten zu der trainierten Person passen, werden die Daten auch zum Training verwendet.

Für die Entdeckung von Ausreißern wurde eine One-Class Support Vector Machine eingesetzt. Eine One-Class SVM ist ein maschineller Lernalgorithmus, der in der Lage ist, Ausreißer in einem Datensatz zu erkennen. Im gewählten Beispiel ist nur eine Klasse von Daten vorhanden. Diese Klasse ist beim Demonstrator, die Person, welche das Handy trägt. Die abweichenden Daten oder Ausreißer sind Daten, die auf eine andere Person hinweisen und damit einer anderen Klasse zugehören.

Das One-Class SVM konstruiert eine Entscheidungsgrenze um die “normalen” Datenpunkte, sodass ein Bereich begrenzt wird, welcher als “normales” Gebiet gesehen werden kann. Alle Datenpunkte außerhalb dieses Bereiches werden als Außenseiter (outliers) betrachtet. Eine Veranschaulichung dieser Unterscheidung wird im Folgenden gezeigt:

Abbildung 1: One-Class SVM ²

Für Self-ID wurde die Anomaly Detection vorgeschlagen, aber final nicht implementiert, weil der Aufwand für den Forschungsprototypen zu hoch war. Für die Datenaufnahme war die Datenbereinigung ausreichend und Erkennung von Anomalien nicht notwendig. Für das finale Produkte sollte der Vorschlag wieder aufgegriffen werden.

Implementierungshilfe

“Tipps & Tricks”

Verwendete SVM-Parameter:

• Kernel: Gaussian Radial Basis Function (RBF)

• Kernel-Funktionen: “Polynomial” und “Sigmoid” nicht verwendet

Das Gamma beschreibt den Kernel-Koeffizienten. Der Gamma-Parameter bezieht sich auf $ \frac{1}{2*\sigma^2} $ der Formel: $ K(x_i,x_j) = exp(-\frac{| x_i - x_j |^2}{2*\sigma^2}) $

Code-Snippet (Python: Initialisierung One-Class-SVM)

    from sklearn.svm import OneClassSVM

    OneClassSVM.__init__(self, kernel='rbf', degree=3, gamma='scale')

Data-Sanitization

Die Data Sanitization der Input-Daten ist eine Maßnahme zur Verbesserung der Robustheit. Dabei werden zum Beispiel unvollständige Daten bereinigt oder entfernt, um alle Daten in die passende Form zu bringen.

Data Sanitization der Output-Daten ist hingegen dem Schutzziel der Privatsphäre zuzuordnen. Hierbei werden sensible Output-Daten vor deren Ausgabe gefiltert. Als sensibel gelten Daten, wenn sie Rückschlüsse auf die Trainingsdaten des Modells zulassen. Ein Beispiel dafür wären die Konfidenzwerte pro Klasse im Falle von Klassifizierung. Diese können von Angreifern genutzt werden, um stärkere Privacy-Angriffe durchzuführen. Stattdessen wird nur die Klasse mit dem höchsten Konfidenzwert ausgegeben.

Szenario

Unbrauchbare oder fehlerhafte Daten werden gefiltert. Für den Demonstrator Self-ID werden somit falsche Bilder oder Aufnahmen, welche ein Blinzeln beinhalten, entfernt. Die Filterung beinhaltet ebenfalls die Entfernung von nicht benötigten Daten, aus den Daten des Eyetrackers. Die Daten werden normalisiert und skaliert. Ein Teil der Output-Daten sind die Konfidenzwerte, die ausgegeben werden.  Die Konfidenzwerte werden ausschließlich in Prototyp-Phase im Videoclient gezeigt. Im fertigen Produkt soll die Stärke des Vertrauens im Videoclient für den betrachteten Videoanrufteilnehmer abstrakter gezeigt werden.

Bei SeamlessMe ist eine Activity Recognition des Authentifizierungsmodels vorgeschaltet. Nur Daten, die dem Laufmuster eines Menschen entsprechen, werden für die Gang-Authentifizierung verwendet. Dadurch wird bereits eine Data Sanitization der Input-Daten durchgeführt.

Erfahrungswerte

Data Sanitization der Input-Daten

Eine Erfahrung, die gemacht wurde, beinhaltet die Annäherung an den korrekten Schwellwert für die Filterung. Dabei sollte beachtet werden, dass keine Trainingsdaten entfernt werden, welche noch genug Aussagekraft haben, obwohl ein kleinerer Teil invalide ist. Für das Ermöglichen der Vergleichbarkeit im Rahmen des Demonstrators Self-ID wird eine minimale Anzahl an Datenpunkten vor dem Präsentieren eines Bildes und eine minimale Anzahl an Datenpunkte nach dem Präsentieren des Bildes errechnet. Datenpunkte, die aus diesem Fenster fallen, werden entfernt, sodass alle Versuche gleich lang sind. Die minimale Anzahl der Datenpunkte beschreibt den kürzesten Zeitraum, der die Aufnahme nicht verfälscht. Die Unterschiede der Aufnahmen ergeben sich aus der Latenz des Eyetrackers.

Data Sanitization der Output-Daten

Wie im Abschnitt “Szenario” beschrieben, wird für die Interpretation der Ergebnisse der Modellerstellung eine Protokollierung der Ergebnisse der Modelle benötigt. Jeder Durchlauf mit verschiedenen Parametern wurde protokolliert und abgelegt. Die Log-Dateien beschreiben die Veränderungen der Leistungsmetriken, welche durch die Veränderung der Eingabeparameter verursacht werden . Diese Protokollierung beinhaltete die Konfidenzwerte aller Klassen. Für die Optimierung der Modelle war eine Übersicht dieser Werte von Nöten. Für die später fertige Anwendung werden die Werte nicht mehr mitgeliefert, sodass keine Rückschlüsse auf die Trainingsdaten des Modells zugelassen werden. Sinnhaft ist ein Feedback zwischen Benutzer und Anwendung, wenn ein Vertrauensniveau zurückgegeben werden soll. Ein Beispiel dafür ist, dass innerhalb der Demonstratoren, die Erkennung von Klassen gekennzeichnet werden sollte.

Implementierungshilfe

“Tipps & Tricks”

Innerhalb des Forschungsprojekts wurde mit Zeitreihen gearbeitet. Eine Art der Datenbereinigung ist die Normalisierung von Daten. In diesem Themenbereich hat sich die Quelle Normalization and Bias in Time Series Data³ von Aishwarya Asesh bewährt

Code-Snippet

    def normalize(x):
        minimum = np.min(x)
        maximum = np.max(x)
        y = (x - minimum) / (maximum - minimum)

        return np.array(y)

Differential Privacy

Differential Privacy (DP) ist eine populäre Metrik, mit welcher der Einfluss einzelner Daten auf das Ergebnis einer Datenverarbeitung bemessen wird. Dies entspricht gleichzeitig dem Privatsphäreverlust der Personen, zu denen die Daten gehören. Der Privatsphäreverlust wird durch das Hinzufügen von Rauschen in der Datenverarbeitung begrenzt. Ursprünglich kommt DP aus dem Bereich Datenbanken, wird aber seit einigen Jahren auch für Privatsphäre bewahrendes ML benutzt.

Szenario

Differential Privacy wurde innerhalb des Self-ID-Demonstrators erprobt, um festzustellen welche Auswirkungen Rauschen auf die Vorhersagequalität hat.

Für die Betrachtung der Auswirkungen von Differential Privacy (DP) wurde eine öffentlich verfügbare Bibliothek verwendet. Diffprivlib⁴ ist eine allgemeine Bibliothek zum Experimentieren, Untersuchen und Entwickeln von Anwendungen im Bereich der differentiellen Privatsphäre.

Erfahrungswerte

Der Einfluss von Differential Privacy führte bei allen betrachteten Klassen zu einer Verringerung der Werte der Metriken. Precision, Recall und F1-Score haben bei allen Klassen abgenommen. Der Einsatz von Differential Privacy kann mit dem Hinzufügen von Rauschen verglichen werden, sodass eine Abwägung zwischen Vorhersagequalität und Schutz vorgenommen werden muss. Zu viel Rauschen kann die Genauigkeit der Vorhersagen beeinträchtigen, während zu wenig Rauschen die Privatsphäre gefährdet.

Abbildung 2: Unterschiede der Metriken

Das Verrauschen von Eingabedaten wird kritisch betrachtet. Hierbei wird auf das Paper “Jekyll and Hyde: On The Double-Faced Nature of Smart-Phone Sensor Noise Injection” verwiesen. Dabei wird die Verrauschung von Smartphone-Sensordaten beobachtet, die für die Authentifizierung der Gangart verwendet werden.

Der Einfluss von “Geräuschinjektion auf die durchschnittlichen F-Scores, die für die gangbasierte Authentifizierung erzielt werden” kann folgendem Graph aus dem Paper entnommen werden:

Abbildung 3: Einfluss von Differential Privacy

Dabei kann gezeigt werden, wie sich der F-Score signifikant senkt, wenn mehr Rauschen hinzugefügt wird. Für die Funktionalität von SeamlessMe ist eine hohe Genauigkeit wichtig, sodass eine Person mit hoher Wahrscheinlichkeit wiedererkannt werden kann.

Implementierungshilfe

“Tipps & Tricks”

Zur Veranschaulichung der Ergebnisse wird die Nutzung von matplot empfohlen, wie es in den oberen Diagrammen exemplarisch zu sehen ist.

Code-Snippet

Beispieleinsatz der Differential Privacy Bibliothek

    from diffprivlib.models import GaussianNB

    clf = GaussianNB()
    clf.fit(X_train, y_train)

    clf.predict(X_test)

Geräteattestierung

Bei der Geräteattestierung wird die Integrität eines Gerätes (z. B. eines Smartphones) durch eine kryptografische Signatur einer vertrauenswürdigen Komponente – z. B. Trusted Execution Environment (TEE), Secure Element (SE) – bestätigt. Die dafür eingesetzten technischen Mechanismen unterscheiden sich je nach Implementierung, generell soll jedoch bestätigt werden, dass das Gerät sich in einem bestimmten Zustand befindet, der als nicht kompromittiert angesehen wird. Geräteattestierung kann beispielsweise genutzt werden, um Eingaben von kompromittierten Geräten abzulehnen und somit die Robustheit eines ML-Systems zu stärken.

Diese Schutzmaßnahme wurde im Rahmen der Demonstratoren des Verbundprojektes SENSIBLE-KI nicht implementiert, da nur einer der Demonstratoren eine netzwerkbasierte Architektur hat, welche den Einsatz der Geräteattestierung begründen würde. Der Client für diesen wurde jedoch zunächst als Desktop-Applikation implementiert. Da im Projektrahmen keine Schutzmaßnahmen für Desktop Geräte untersucht wurden und eine Geräteattestierung nach unserem Kenntnisstand nicht üblich ist, konnte diese Schutzmaßnahme bei keinem der Demonstratoren sinnvoll eingesetzt werden.

Datenattestierung

Wie bei der Geräteattestierung wird auch bei der Datenattestierung eine kryptografische Signatur einer vertrauenswürdigen Komponente verwendet. Diesmal wird jedoch die Signatur über ein bestimmtes Datum berechnet und attestiert, dass dieses bestimmte Eigenschaften hat (z.B., dass die Daten aus einer bestimmten Hardware stammen). Auch diese Form der Attestierung wird zur Stärkung der Robustheit eingesetzt.

Diese Schutzmaßnahme wurde im Rahmen der Demonstratoren des Verbundprojektes SENSIBLE-KI nicht implementiert, da keine Daten von externen Sensorknoten oder Mobilgeräten gesammelt werden, welche attestiert werden könnten, und die Maßnahme zusätzlich nur von spezifischer Hardware umgesetzt werden kann, die für die Entwicklung der Demonstratoren nicht sinnvoll eingesetzt werden konnte. Die Evaluierungen der Maßnahme im Rahmen von AP2 zeigte jedoch eine erhöhte Latenz bei der Datensammlung, welche die Maßnahme je nach Art der Datensammlung der ML-Anwendung unpraktikabel machen könnte.

Modell-Signatur

Bei Modellupdates über das Netzwerk sollte durch Signatur des Modells sichergestellt werden, dass der Empfänger das korrekte Modell erhalten hat. Die Signatur wird vom Sender erstellt und auf dem Endgerät vor der Ausführung geprüft. Besonders bei kritischen Anwendungen ist die Durchführung der Attestierung und Signatur mittels einer vertrauenswürdigen Komponente sinnvoll. Diese Maßnahme stärkt die Robustheit des ML-Systems.

Diese Schutzmaßnahme wurde im Rahmen der Demonstratoren des Verbundprojektes SENSIBLE-KI nicht implementiert, da bei keiner der beiden Anwendungen geplant ist, Modell-Updates über das Netzwerk zu übertragen. Die früher im Projekt erfolgten Evaluierungen der Maßnahme ergaben eine erhöhte Latenz beim Start der Anwendung, deren Länge stark von der zur Signatur und Verifikation genutzten Hardware abhing. Weiterhin ist zu beachten, dass zur Implementierung dieser Maßnahme in einem TEE das Implementieren und Ausführen einer eigenen Trusted Application notwendig wäre, was auf den üblichen Mobilgeräten beispielsweise aktuell nicht ohne weiteres möglich ist.

Verschlüsselung der Output-Daten

Eine Maßnahme zur Verbesserung der Privatsphäre ist das Verschlüsseln von personenbezogenen Output-Daten vor der Übertragung oder Speicherung. Besonders bei hohem Personenbezug ist es empfehlenswert, zur Verschlüsselung eine vertrauenswürdige Komponente zu nutzen, da diese einen besseren Schutz für das verwendete Schlüsselmaterial bietet.

Szenario

Die Verschlüsselung wurde innerhalb des SeamlessMe-Demonstrators erprobt.

Ablegen von Schlüsselmaterial

iOs:

Das Schlüsselmaterial wird in der Secure Enclave gespeichert. Die Secure Enclave ist eine abgesicherte Hardwarekomponente. Dieser isolierte Bereich im Prozessorchip dient als Sicherheit und Schutz sensibler Daten.

Android:

Das Schlüsselmaterial wird in der hardwaregestützter Keystore gespeichert. Der hardwaregestützter Keystore ist eine physische Hardwarekomponente, die für die sichere Speicherung von kryptografischen Schlüsseln und sensiblen Daten verantwortlich ist. Nicht auf allen Geräten die kryptografischen Algorithmen unterstützt, die für die Absicherung der Kommunikation benötigt werden. Dies wird bei der Implementierung einen Mehraufwand darstellen.

Erfahrungswerte

Korrekte Wahl von Verschlüsselungsalgorithmen:

Die Wahl eines robusten Verschlüsselungsalgorithmus wie AES oder RSA steht in Abhängigkeit mit dem gewünschten Sicherheitsniveau.

Schlüssellänge und Schlüsselverwaltung:

Es wird empfohlen eine angemessene Schlüssellänge zu wählen, da eine längere Schlüssellänge eine höhere Sicherheit bietet. Die genutzten Schlüssel sollten ebenfalls sicher verwaltet werden und nur autorisierten Personen zugänglich sein. Regelmäßiges Rotieren der Schlüssel wird ebenfalls empfohlen.

Keine Performanceeinbußen

Die im Verhältnis kleineren Datenmengen im Projekt führten nicht zu Leistungseinbußen.

Implementierungshilfe

Für das Erweitern der Recherche und bei Bedarf nach aktuellen Beispielen wird die Dokumentation zum Android Keystore System⁵ und der iOS Secure Enclave⁶ empfohlen.

Inferenz in TEE

Eine Möglichkeit, die Schutzziele der Vertraulichkeit, Robustheit und der Privatsphäre zugleich umzusetzen, ist die Ausführung der Inferenz einer ML-Anwendung innerhalb eines Trusted Execution Environments als sogenannte Trusted Application. Somit käme das fertig trainierte Modell nicht in Kontakt mit potenziell bösartigen Drittapplikationen und wäre selbst bei kompromittiertem Betriebssystem geschützt. Diese Maßnahme ist leider aktuell noch nicht praktisch umzusetzen ohne hohe technische Hürden und signifikante Performance-Einbußen.

Die Schutzmaßnahme wurde dementsprechend im Rahmen der Demonstratoren des Verbundprojektes SENSIBLE-KI nicht implementiert.