De ELS-klasse (
EncryptedLocalStore
) biedt een manier om lokale gegevens gecodeerd op te slaan die u kunt gebruiken als een kleine cache voor de privégegevens van een toepassing. ELS-gegevens kunnen niet worden gedeeld tussen toepassingen. De bedoeling van ELS is het mogelijk maken dat een toepassing opnieuw gemaakte items, zoals aanmeldingsgegevens en andere privégegevens, gemakkelijk kan opslaan. ELS-gegevens moeten niet worden beschouwd als permanente gegevens, zoals hieronder beschreven in "Beperkingen van de gecodeerde lokale opslag" en "Tips en trucs".
In de gecodeerde lokale opslag kunt u cache-informatie opslaan die moet worden beveiligd, zoals aanmeldingsgegevens voor webservices. Deze gecodeerde lokale opslag, ofwel ELS (Encrypted Local Store), is geschikt voor het opslaan van informatie die andere gebruikers niet mogen zien. De gegevens worden dan echter niet beveiligd tegen andere processen die onder dezelfde gebruikersaccount worden uitgevoerd. De ELS is dus niet geschikt voor het beveiligen van geheime toepassingsgegevens, zoals DRM- of coderingssleutels.
Op bureaubladplatforms maakt AIR in Windows van DPAPI, in Mac OS en iOS van KeyChain en in Linux van KeyRing of KWallet gebruik om de gecodeerde lokale opslag te koppelen aan elke toepassing en gebruiker. De gecodeerde lokale opslag gebruikt AES-CBC 128-bits codering.
Op Android worden de gegevens die door de klasse EncryptedLocalStorage zijn opgeslagen niet gecodeerd. De gegevens worden in plaats daarvan beveiligd door beveiliging op gebruikersniveau die wordt verschaft door het besturingssysteem. Het Android-besturingssysteem wijst een eigen gebruikers-id toe aan elke toepassing. Toepassingen kunnen alleen hun eigen bestanden openen, plus bestanden die zijn gemaakt op openbare locaties (zoals een verwijderbare opslagkaart). Op Android-apparaten met rooting hebben toepassingen met rootingrechten WEL toegang tot de bestanden van andere toepassingen. Op een apparaat met rooting verschaft gecodeerde lokale opslag dus minder goede gegevensbeveiliging dan op een apparaat zonder rooting.
Informatie in de gecodeerde lokale opslag is alleen beschikbaar voor de inhoud van een AIR-toepassing in de beveiligingssandbox van de toepassing.
Als u een AIR-toepassing bijwerkt, hebt u ook in de bijgewerkte versie toegang tot alle bestaande gegevens in de gecodeerde lokale opslag, tenzij:
-
De items zijn toegevoegd met de parameter
stronglyBound
ingesteld op
true
.
-
De bestaande en bijgewerkte versie allebei ouder zijn dan AIR 1.5.3 en de update ondertekend is met een migratiehandtekening.
Beperkingen van de gecodeerde lokale opslag
De gegevens in de gecodeerde lokale opslag worden beveiligd door de verificatiegegevens van het besturingssysteem van de gebruiker. Andere entiteiten hebben alleen toegang tot de gegevens in de opslag als ze zich als de desbetreffende gebruiker kunnen aanmelden. De gegevens zijn echter niet beveiligd tegen toegang vanuit andere toepassingen die door een geverifieerde gebruiker worden uitgevoerd.
Omdat de gebruiker voor deze aanvallen geverifieerd moet zijn, zijn de privégegevens van de gebruiker nog steeds beveiligd (behalve als de gebruikersaccount is gecompromitteerd). Gegevens die uw toepassing eventueel geheim wilt houden voor gebruikers, zoals keys voor licentie- of digitale rechten, zijn echter niet beveiligd. De ELS is dus niet de geschikte locatie om zulke informatie op te slaan. Het is alleen een geschikte locatie voor het opslaan van privégegevens van een gebruiker, zoals wachtwoorden.
De gegevens in de ELS kunnen om verschillende redenen verloren gaan. Een gebruiker kan de toepassing bijvoorbeeld verwijderen en daarmee het gecodeerde bestand. Het is ook mogelijk dat de uitgever-id wordt gewijzigd als resultaat van een update. De lokale gegevensopslag moet dus worden beschouwd als een persoonlijk cachegeheugen, niet als een permanente gegevensopslag.
De parameter
stronglyBound
is afgekeurd en mag niet worden ingesteld op
true
. Het instellen van de parameter op
true
verschaft uw gegevens geen extra beveiliging. Tegelijkertijd gaat toegang tot de gegevens verloren wanneer de toepassing wordt bijgewerkt, ook als de uitgever-id niet wordt gewijzigd.
De gecodeerde lokale opslag kan langzamer werken als de opgeslagen hoeveelheid gegevens groter is dan 10 MB.
Wanneer u een AIR-toepassing verwijdert, worden de gegevens die in de gecodeerde lokale opslag zijn opgeslagen, niet verwijderd.
Tips en trucs
Tips en trucs voor het gebruik van de ELS:
-
Gebruik de ELS om gevoelige gebruikersgegevens zoals wachtwoorden op te slaan (stel stronglyBound in op false).
-
Gebruik de ELS niet om toepassingsgeheimen op te slaan, zoals DRM-sleutels of licentietokens..
-
Verschaf uw toepassing een manier om de gegevens in de ELS opnieuw te creëren als de ELS-gegevens verloren gaan. Vraag de gebruiker bijvoorbeeld om zijn of haar aanmeldinggegevens voor de account, indien nodig, opnieuw in te voeren.
-
Gebruik de parameter
stronglyBound
niet.
-
Als u de parameter
stronglyBound
wel instelt op
true
, dient u opgeslagen items tijdens een update niet te verplaatsen. Het is beter de gegevens na de update opnieuw te maken.
-
Sla alleen relatief kleine hoeveelheden gegevens op. Gebruik een gecodeerde AIR SQL-database voor grotere hoeveelheden gegevens.
Gegevens toevoegen aan de gecodeerde lokale opslagplaats.
Gebruik de statische methode
setItem()
van de EncryptedLocalStore-klasse om gegevens lokaal op te slaan. De gegevens worden opgeslagen in een hashtabel, waarbij tekenreeksen worden gebruikt als sleutels en de gegevens worden opgeslagen als bytearrays.
Met de volgende code wordt bijvoorbeeld een tekenreeks opgeslagen in de gecodeerde lokale opslag:
var str:String = "Bob";
var bytes:ByteArray = new ByteArray();
bytes.writeUTFBytes(str);
EncryptedLocalStore.setItem("firstName", bytes);
De derde parameter van de methode
setItem()
, de parameter
stronglyBound
, is optioneel. Als deze parameter is ingesteld op
true
, koppelt de ELS het opgeslagen item aan de digitale handtekening en onderdelen van de AIR-toepassing waarin het item wordt opgeslagen:
var str:String = "Bob";
var bytes:ByteArray = new ByteArray();
bytes.writeUTFBytes(str);
EncryptedLocalStore.setItem("firstName", bytes, false);
Voor een item dat is opgeslagen terwijl
stronglyBound
op
true
is ingesteld, zullen volgende oproepen van
getItem()
alleen slagen als de oproepende AIR-toepassing identiek is aan de opslaande toepassing (als er geen gegevens in bestanden in de toepassingsmap zijn gewijzigd). Als de oproepende AIR-toepassing niet identiek is aan de opslaande toepassing, genereert de toepassing een uitzonderingsfout wanneer u
getItem()
oproept voor een sterk gebonden item. Als u uw toepassing bijwerkt, kan deze geen sterk gebonden gegevens lezen die eerder in de gecodeerde lokale opslag zijn geschreven. Het instellen van
stronglyBound
op
true
op mobiele apparaten wordt genegeerd, de parameter wordt altijd behandeld als
false
.
Als de parameter
stronglyBound
op
false
is ingesteld (de standaardinstelling) hoeft alleen de uitgevers-id hetzelfde te blijven, zodat de toepassing de gegevens nog steeds kan lezen. De onderdelen van de toepassing kunnen veranderen (en deze moeten door dezelfde uitgever worden ondertekend), maar het hoeven niet precies dezelfde onderdelen te zijn als in de toepassing waarin de gegevens zijn opgeslagen. Bijgewerkte toepassingen met dezelfde uitgever-id als de oorspronkelijke toepassingen hebben nog steeds toegang tot de gegevens.
Opmerking:
In de praktijk levert het instellen van
stronglyBound
op
true
geen aanvullende gegevensbeveiliging op. Een kwaadwillende gebruiker kan een toepassing not steeds aanpassen en toegang krijgen tot de items in de ELS. Bovendien zijn gegevens net zo goed beveiligd tegen externe bedreigingen van niet-gebruikers wanneer
stronglyBound
is ingesteld op
true
als op
false
. Daarom wordt het niet aangeraden om
stronglyBound
in te stellen op
true
.