Ga naar hoofdinhoud

Technology, security analysis

Factoren bij het beveiligen van app- en cloudgegevens

Aidan FitzpatrickGepubliceerd op 10 maart 2017Bijgewerkt op 13 maart 2020
Op deze pagina
Cover image for: Factoren bij het beveiligen van app- en cloudgegevens

Nu er steeds meer waardevolle gegevens in de cloud worden opgeslagen, is het des te belangrijker dat ze goed beschermd zijn. Sterke beveiligingsmaatregelen rond clouddiensten zoals iCloud komen iedereen ten goede: eindgebruikers, cloudproviders zoals Apple en ecosysteemplatforms zoals Reincubate.

Mechanismen om deze gegevens te beschermen komen in verschillende vormen voor, en Apple heeft een goede staat van dienst bij het implementeren ervan. Dit artikel bekijkt een aantal technieken die zij, en het team van Reincubate, hebben gebruikt.

Sla minder op, als het kan

Ten eerste loont het om minder op te slaan in plaats van meer. Daar zijn voorbeelden van waarbij gegevens nooit in iCloud zijn opgeslagen, zoals gezichtsherkenningsgegevens uit Foto’s, die niet in de iCloud-fotobibliotheek staan maar lokaal in de cache worden bewaard. Gegevens van Apples HealthKit, HomeKit en TouchID worden op dezelfde manier behandeld, net als de gezichtsherkenningsgegevens voor het Android-vergrendelscherm. Natuurlijk is dit vaak een afweging tussen gemak en de waarde van het synchroniseren van die gegevens tussen apparaten. Sommige systemen kiezen een gedeeltelijke aanpak. iMessage bewaart bijvoorbeeld een beperkte hoeveelheid inhoud in de cloud, maar vertrouwt erop dat andere gegevens rechtstreeks tussen apparaten worden gesynchroniseerd.

Beveiligde berichtendiensten zoals Telegram of WhatsApp kiezen een volledig andere aanpak. Omdat er geen gegevens (of althans niet veel) op hun servers worden opgeslagen, moet een uitgebreide set gegevens in elke back-up van een apparaat zitten, zodat een gebruiker zinvol een back-up kan maken en terugzetten. Om de veiligheid te waarborgen, wassen die appontwikkelaars in zekere zin hun handen van het beheer van die gegevens en laten ze dat over aan de eindgebruiker, die ervoor kan kiezen om zijn of haar apparaten lokaal of in de cloud te back-uppen.

Er zijn dus twee uitersten, en je kunt WhatsApp, met weinig in de cloud en alles in de back-up, afzetten tegen Facebook Messenger, dat niets in een apparaatback-up bewaart omdat alles gemakkelijk beschikbaar is in de cloud, en dat ook moet zijn om Facebook zijn webinterface te laten bieden.

Er is hier geen juiste oplossing, maar het is het overdenken waard: het gebruik van een app die deze gegevens host, vereist dat de appontwikkelaar ze veilig beheert, terwijl gebruikers vaak in het ongewisse worden gelaten over wat er wordt opgeslagen en hoe. Het gebruik van een app die gegevens niet centraal opslaat, betekent dat de eindgebruiker zelf verantwoordelijk is voor de beveiliging van zijn of haar back-upgegevens, tenzij die worden overgelaten aan de cloud van het platform, zoals bij iCloud-back-ups en de apparaatback-ups van Google voor Android 7.0 en nieuwer.

Interessant is dat sommige appmakers, zoals in onderstaande grafiek te zien is, beide uitersten bezetten. De Snapchat-app slaat bijna al zijn gegevens in de cloud op, terwijl de fysieke uitbreiding van de app, Spectacles, al zijn gegevens lokaal op het apparaat bewaart.

Verschillende benaderingen van de beveiliging van appgegevens

Verschillende benaderingen van de beveiliging van appgegevens

Hoewel ze niet breed zijn uitgerold, zijn Snapchat Spectacles vrij onveilig: door zeven seconden op de “snap”-knop te drukken, kan een hacker ze koppelen aan een nieuwe telefoon en alle onversleutelde snaps bemachtigen die de rechtmatige eigenaar erop heeft opgeslagen. Dat staat in schril contrast met de beveiligingsprincipes van de Apple Watch.

Sterke versleuteling

Dat brengt ons bij de tweede cruciale techniek: sterke versleuteling, bij voorkeur met onvolledige opslag van de sleutels. Als gegevens te gevoelig worden geacht om zo in een back-up te zetten dat ze toegankelijk zijn als een apparaat kapotgaat of wordt vervangen, zijn er andere technieken beschikbaar. Door het gebruik van een specifiek apparaat te vereisen, gebruikt de functie “Secret Conversations” van Facebook hardware-identificaties om inhoud te versleutelen. Gaat het apparaat verloren, dan is de inhoud praktisch onherstelbaar.

Sommige systemen gebruiken een vergelijkbare techniek waarbij een apparaatspecifiek token kan worden aangemaakt, zodat slechts een beperkt aantal apparaten tegelijk toegang heeft tot inhoud. Snapchat en WhatsApp gebruiken elk een variant hiervan. Bij het inloggen op Snapchat op een apparaat wordt een token aangemaakt en gedeeld tussen de servers van Snapchat en het apparaat. Als dezelfde gebruiker op een ander apparaat inlogt, wordt een nieuw token aangemaakt dat het token in de cloud vervangt, en wordt het eerste apparaat gedwongen uit te loggen omdat het inkomende berichten niet meer kan ontsleutelen. Bij gebruik op onveilige systemen heeft deze techniek een duidelijke kwetsbaarheid: het token kan worden gekopieerd en elders worden gebruikt. Als er een argument nodig was waarom het een verschrikkelijk slecht idee is om een Android-apparaat met root of een iOS-apparaat met jailbreak te gebruiken, dan is dit het, en het verklaart ook waarom er voorlopig waarschijnlijk geen webclient voor Snapchat komt.

Het is één ding om mogelijk geheime Facebook-berichten kwijt te raken, maar sommige gegevens zijn zowel zeer gevoelig als zeer waardevol voor hun eigenaar. Het lijkt tegenintuïtief, maar als de persoonlijke waarde van de gegevens groot genoeg is, worden ze vaak zo opgeslagen dat er veel mogelijke manieren zijn om ze te ontsleutelen of te herstellen. Daarbij wordt veiligheid ingeruild voor minder onpraktisch gedoe. Zo is er een massa gegevens verbonden aan iCloud- en Google-accounts, waaronder in beide gevallen een vorm van gedistribueerde cloudsleutelhanger waarin alle wachtwoorden van een gebruiker staan. Bovendien betekent de promotie van Google van hun accounts als authenticatiemechanisme op andere sites via OAuth dat het onherstelbaar verliezen van toegang tot zulke accounts een bittere pil zou zijn.

Omdat deze accounts te waardevol worden geacht om het permanente verlies ervan zomaar te riskeren, wordt een tussenoplossing gebruikt waarbij gegevens in de cloud worden opgeslagen, maar versleuteld met een token of wachtwoord dat alleen de gebruiker bewaart en dat zelf niet wordt opgeslagen. Daarom zijn, bijvoorbeeld, bij het inloggen in een verse installatie van de Chrome-browser van Google de in de cloud opgeslagen wachtwoorden pas beschikbaar nadat in de browser een tweede synchronisatiewachtwoord is ingevoerd.

De last van versleuteling delen

Tim Cook van Apple, die serieus en op het gebied van beveiliging in de kern gelijk heeft, bevestigde pas vorig jaar dat hij in deze techniek gelooft:

For many years, we have used encryption to protect our customers’ personal data because we believe it’s the only way to keep their information safe. We have even put that data out of our own reach, because we believe the contents of your iPhone are none of our business.

— Tim Cook in “A Message to Our Customers”

Los van al het andere kan dit cloudproviders helpen om volledige gebruikersgegevens niet aan overheidsinstanties bekend te maken. Als ze door een bevel worden verplicht ze te verstrekken, kunnen ze dat doen zonder de gegevens van een gebruiker rechtstreeks bloot te leggen, omdat de gegevens nog moeten worden ontsleuteld, en dat kan alleen met een sleutel die alleen de eindgebruiker heeft.

Soms, zoals bij meerfactorauthenticatie (MFA), tweefactorauthenticatie (2FA) of tweestapsverificatie (2SV), betekent dit dat de extra sleutel alleen naar een bepaald apparaat kan worden gestuurd of door dat apparaat kan worden gegenereerd. Banken en VPN’s gebruiken vaak fysieke kaartlezers of beveiligde seedgeneratoren, die vormen zijn van tijdgebaseerde eenmalige-wachtwoordgeneratoren (OTP of TOTP). Zowel Google als Apple bieden eenvoudige MFA via sms en volledige 2FA-systemen, waarbij dat van Google HOTP/OATH gebruikt en dat van Apple propriëtair is.

Wanneer beveiligings- of opsporingsdiensten (LEA) deze versleutelde gegevens hebben maar geen sleutel van de eindgebruiker om ze te ontsleutelen, kunnen ze proberen ze met brute kracht te kraken door met krachtige machines de gegevens te testen tegen automatisch geraden wachtwoorden. Apples iOS heeft hier een enorm voordeel ten opzichte van Googles Android: omdat Apple de hardware in zijn apparaten strak in de hand heeft, kan het versleutelingstechnieken ontwerpen die alleen de eigen hardware snel kan uitvoeren en die andere apparaten, zoals desktopcomputers, langzaam uitvoeren. Toen Reincubate het eerste bedrijf ter wereld werd dat het ontsleutelen van gegevens van 10.2 ondersteunde, was het belang niet alleen dat het bedrijf als eerste begreep hoe 10.2 werkte, maar dat wij als eerste het snelle ontsleutelen van Apples slimme techniek konden opschalen. Doordat elke ontsleutelpoging op gangbare hardware een aantal seconden kost, werd het voor hackers of opsporingsdiensten onpraktisch om met brute kracht te kraken.

Beveiliging door obscuriteit

Het zou niet passen om deze technieken te bespreken zonder er een te behandelen waar Apple bijzonder goed in is: beveiliging door obscuriteit. Door geen openbare API’s, gedetailleerde documentatie of zelfs maar veel communicatie over deze systemen vrij te geven, kan het bedrijf voorkomen dat hackers worden gewezen op mogelijke aanvalsvectoren. Lange tijd was het argument tegen obscuriteit dat openheid en open source tot betere beveiligingsresultaten leidden, maar dat was vóór de ontdekking in 2014 dat OpenSSL, een cruciale open-sourcebeveiligingsbibliotheek die vrijwel alles gebruikt, fundamenteel onveilig was en dat vrijwel altijd al was.

Neem contact met ons op als je wilt onderzoeken hoe je met app- of cloudgegevens kunt werken, of als je de dynamiek van de verschillende benaderingen beter wilt begrijpen.


Over de auteur

Aidan Fitzpatrick

Oprichter, CEO

Aidan richtte Reincubate op in 2008, nadat hij ’s werelds eerste tool voor iOS-gegevensherstel had gebouwd. Sindsdien heeft hij het bedrijf uitgebouwd tot een van ’s werelds toonaangevende ISV’s, in samenwerking met bedrijven als AMD, Qualcomm en HP om betekenisvolle machine-learning-functies voor videosoftware te ontwikkelen, met als uithangbord het Camo-app-ecosysteem. Onder Aidans leiding heeft Reincubate vier keer de hoogste zakelijke onderscheiding van het VK gewonnen, een plek veroverd op de 100 Tech-lijst van The Sunday Times, en erkenning in de sector gekregen met nominaties voor de Apple Design Award en de App Store Awards. Zijn werk en technieken worden vaak aangehaald in wetenschappelijke publicaties over mobiele forensica, en hij is uitgenodigd om te spreken op evenementen georganiseerd door bedrijven als Google, Microsoft en Snap.


Gerelateerde inhoud


Populaire artikelen

Logo van de King's Award for Enterprise

King's Award for Enterprise: Reincubate heeft vier keer de hoogste officiële zakelijke onderscheiding van het Verenigd Koninkrijk gewonnen, het meest recent als erkenning voor de uitzonderlijke groei van het bedrijf in de afgelopen drie jaar.

Onze relaties met gebruikers en partners staan centraal in onze waarden en de producten die we maken. Bekijk onze reviews om te horen wat zij over ons te zeggen hebben.

ISO 27001-gecertificeerd door Centre for Assessment, geaccrediteerd door UKAS

© 2008-2026 Reincubate Ltd. Alle rechten voorbehouden. Ingeschreven in Engeland en Wales onder nr. 5189175, btw-nummer GB151788978. Camo®, Streamlight® en Reincubate® zijn geregistreerde handelsmerken. Octrooien aangevraagd.

Hulp