Verschlüsselter lokaler Speicher

Die EncryptedLocalStore -Klasse (ELS) stellt einen Mechanismus für verschlüsselten lokalen Speicher bereit, den Sie als kleinen Cache für die privaten Daten einer Anwendung verwenden können. ELS-Daten können nicht von Anwendungen gemeinsam genutzt werden. ELS hat den Zweck, einer Anwendung das Speichern von leicht wiederherzustellenden Elementen wie Anmeldeinformationen und anderen privaten Informationen zu ermöglichen. ELS-Daten sollten nicht als dauerhaft betrachtet werden; siehe „Einschränkungen des verschlüsselten lokalen Speichers“ und „Empfohlene Verfahren“ weiter unten.

Hinweis: Zusätzlich zum verschlüsselten lokalen Speicher ermöglicht AIR auch die Verschlüsselung von Inhalten, die in SQL-Datenbanken gespeichert sind. Weitere Informationen finden Sie unter Verwenden von Verschlüsselung mit SQL-Datenbanken .

Es empfiehlt sich, den verschlüsselten lokalen Speicher zum Zwischenspeichern von Daten zu verwenden, die gesichert werden müssen (z. B. Anmeldeinformationen für Webdienste). Der ELS eignet sich für die Speicherung von Informationen, die für andere Benutzer nicht zugänglich sein sollen. Er schützt die Daten jedoch nicht vor anderen Prozessen, die unter demselben Benutzerkonto ausgeführt werden. ELS eignet sich deshalb nicht für den Schutz geheimer Anwendungsdaten wie DRM oder Verschlüsselungsschlüssel.

Auf Desktopplattformen verwendet AIR DPAPI unter Windows, KeyChain unter Mac OS und iOS sowie KeyRing oder KWallet unter Linux, um den verschlüsselten lokalen Speicher den einzelnen Anwendungen und Benutzern zuzuordnen. Die Verschlüsselung im lokalen Speicher erfolgt mit einer AES-CBC-128-Bit-Verschlüsselung.

Unter Android werden die von der EncryptedLocalStorage-Klasse gespeicherten Daten nicht verschlüsselt. Stattdessen werden die Daten durch die vom Betriebssystem bereitgestellte Sicherheit auf Benutzerebene geschützt. Das Android-Betriebssystem weist jeder Anwendung eine separate Benutzer-ID zu. Anwendungen können nur auf ihre eigenen Dateien zugreifen und auf Dateien, die an öffentlichen Speicherorten erstellt wurden (zum Beispiel auf der austauschbaren Speicherkarte). Beachten Sie, dass auf gerooteten Android-Geräten Anwendungen, die mit Root-Berechtigung ausgeführt werden, auf die Dateien anderer Anwendungen zugreifen können. Auf einem gerooteten Gerät bietet der verschlüsselte lokale Speicher deshalb weniger Datensicherheit als auf einem nicht gerooteten Gerät.

Die im verschlüsselten lokalen Speicher enthaltenen Informationen stehen AIR-Anwendungsinhalten nur in der Sicherheits-Sandbox der Anwendung zur Verfügung.

Wenn Sie eine AIR-Anwendung aktualisieren, behält die aktualisierte Version den Zugriff auf alle vorhandenen Daten im verschlüsselten lokalen Speicher, es sei denn:

  • Die Elemente wurden hinzugefügt, während ihr stronglyBound -Parameter auf true gesetzt war

  • Die vorhandene und die aktualisierte Version wurden beide vor AIR 1.5.3 veröffentlicht und das Update wurde mit einer Migrationssignatur signiert.

Einschränkungen des verschlüsselten lokalen Speichers

Die Daten im verschlüsselten lokalen Speicher sind durch die Authentifizierungsdaten des Betriebssystems des Benutzers geschützt. Andere Entitäten haben keinen Zugriff auf den Speicher, solange sie sich nicht als der betreffende Benutzer anmelden können. Die Daten sind jedoch nicht vor dem Zugriff durch andere Anwendungen, die von einem authentifizierten Benutzer ausgeführt werden, geschützt.

Da der Benutzer authentifiziert werden muss, damit diese Angriffe funktionieren, sind die vertraulichen Daten eines Benutzers immer noch geschützt (sofern nicht das Benutzerkonto selbst unbefugt verwendet wird). Daten, die Ihre Anwendung vor Benutzern geheim halten möchte, zum Beispiel Lizenzschlüssel oder DRM-Schlüssel, sind jedoch nicht sicher. Deshalb ist der verschlüsselte lokale Speicher nicht der geeignete Ort für die Speicherung dieser Informationen. Er ist lediglich ein geeigneter Speicherort für die persönlichen Daten eines Benutzers, zum Beispiel Kennwörter.

Daten im ELS können aus verschiedenen Gründen verloren gehen. Der Benutzer könnte die Anwendung zum Beispiel deinstallieren und die verschlüsselte Datei löschen. Oder die Herausgeber-ID wird im Rahmen eines Updates geändert. Deshalb sollte der verschlüsselte lokale Speicher als privater Zwischenspeicher eingesetzt werden, nicht jedoch als permanenter Datenspeicher.

Der stronglyBound -Parameter ist veraltet und sollte nicht auf true gesetzt werden. Das Einstellen des Parameters auf true bringt keinerlei zusätzlichen Schutz für Daten. Gleichzeitig geht der Zugriff auf die Daten verloren, wenn die Anwendung aktualisiert wird, selbst wenn die Herausgeber-ID gleich bleibt.

Der verschlüsselte lokale Speicher arbeitet möglicherweise langsamer, wenn mehr als 10 MB Daten gespeichert sind.

Bei der Deinstallation einer AIR-Anwendung werden die Daten im verschlüsselten lokalen Speicher nicht gelöscht.

Empfohlene Verfahren

Zu den bewährten Verfahren bei der Verwendung des verschlüsselten lokalen Speicher gehört Folgendes:

  • Speichern Sie vertrauliche Benutzerdaten, wie Kennwörter, im verschlüsselten lokalen Speicher (indem Sie stronglyBound auf false setzen).

  • Speichern Sie im verschlüsselten lokalen Speicher keine vertraulichen Anwendungsdaten, wie DRM-Schlüssel oder Lizenz-Token.

  • Stellen Sie für Ihre Anwendung eine Möglichkeit bereit, die im ELS gespeicherten Daten wiederherzustellen, falls sie verloren gehen sollten. Dies ist zum Beispiel möglich, indem der Benutzer ggf. zur erneuten Eingabe seiner Benutzerkontodaten aufgefordert wird.

  • Verwenden Sie nicht den stronglyBound -Parameter.

  • Wenn Sie stronglyBound auf true setzen, migrieren Sie gespeicherte Elemente während eines Updates nicht. Erstellen Sie die Daten stattdessen nach dem Update erneut.

  • Speichen Sie nur relativ kleine Datenmengen. Für größere Datenmengen sollten Sie eine AIR SQL-Datenbank mit Verschlüsselung verwenden.

Hinzufügen von Daten zum verschlüsselten lokalen Speicher

Speichern Sie Daten unter Verwendung der statischen setItem() -Methode der EncryptedLocalStore-Klasse im verschlüsselten lokalen Speicher. Die in einer Hash-Tabelle gespeicherten Daten verwenden Strings als Schlüssel, wobei die Daten als Byte-Arrays gespeichert sind.

Im folgenden Beispielcode wird ein String im verschlüsselten lokalen Speicher gespeichert: 

var str:String = "Bob"; 
var bytes:ByteArray = new ByteArray(); 
bytes.writeUTFBytes(str); 
EncryptedLocalStore.setItem("firstName", bytes);

Der dritte Parameter der Methode setItem() , der Parameter stronglyBound , ist optional. Wenn dieser Parameter auf true gesetzt ist, bindet der verschlüsselte lokale Speicher das gespeicherte Element an die digitale Signatur und die Bit der speichernden AIR-Anwendung. 

var str:String = "Bob"; 
var bytes:ByteArray = new ByteArray(); 
bytes.writeUTFBytes(str); 
EncryptedLocalStore.setItem("firstName", bytes, false);

Bei einem Element, dessen stronglyBound -Parameter beim Speichern auf true gesetzt ist, sind nachfolgende Aufrufe von getItem() nur erfolgreich, wenn die aufrufende AIR-Anwendung identisch ist mit der speichernden Anwendung (d. h., wenn in den Dateien im Anwendungsverzeichnis keine Daten geändert wurden). Sind die aufrufende und die speichernde Anwendung nicht identisch, wird eine Error-Ausnahme ausgelöst, wenn Sie für ein stark gebundenes Element getItem() aufrufen. Wenn Sie die Anwendung aktualisieren, können stark gebundene Daten, die zuvor in den verschlüsselten lokalen Speicher geschrieben wurden, nicht gelesen werden. Das Festlegen von stronglyBound auf true wird bei mobilen Geräten ignoriert; der Parameter wird immer als false behandelt.

Ist der stronglyBound -Parameter auf false gesetzt (Standardwert), muss nur die Hersteller-ID gleich bleiben, damit die Anwendung die Daten lesen kann. Die Bit der Anwendung können sich ändern (und sie müssen von demselben Herausgeber signiert werden). Es müssen aber nicht dieselben Bit sein wie in der Anwendung, in der die Daten gespeichert wurden. Aktualisierte Anwendungen mit derselben Herausgeber-ID wie das Original können auch weiterhin auf die Daten zugreifen.

Hinweis: Durch Einstellen von stronglyBound auf true entsteht in der Praxis kein zusätzlicher Schutz für die Daten. Ein Benutzer mit bösartigen Absichten könnte eine Anwendung nach wie vor ändern, um Zugriff auf die Daten im verschlüsselten lokalen Speicher zu erhalten. Außerdem ist der Schutz der Daten vor externen Bedrohungen, die nicht von Benutzern ausgehen, gleichermaßen wirksam, unabhängig davon, ob stronglyBound auf true oder false eingestellt ist. Deshalb sollte stronglyBound nicht auf true gesetzt werden.

Zugriff auf die Daten im verschlüsselten lokalen Speicher

Sie können mithilfe der Methode EncryptedLocalStore.getItem() einen Wert aus dem verschlüsselten lokalen Speicher abrufen. Hier ein Beispiel: 

var storedValue:ByteArray = EncryptedLocalStore.getItem("firstName"); 
trace(storedValue.readUTFBytes(storedValue.length)); // "Bob"

Entfernen von Daten aus dem verschlüsselten lokalen Speicher

Sie können einen Wert aus dem verschlüsselten lokalen Speicher mithilfe der Methode EncryptedLocalStore.removeItem() löschen. Hier ein Beispiel: 

EncryptedLocalStore.removeItem("firstName");

Und durch Aufruf der Methode EncryptedLocalStore.reset() können alle Daten aus dem verschlüsselten lokalen Speicher löschen. Auch hierzu ein Beispiel: 

EncryptedLocalStore.reset();