Factoren bij het beveiligen van app- en cloudgegevens
Met toenemende hoeveelheden waardevolle gegevens die zijn opgeslagen in de cloud, is het des te belangrijker dat deze krachtig wordt beschermd. Sterke beveiligingsmaatregelen rond cloud-datadiensten zoals de iCloud komen iedereen ten goede: eindgebruikers, cloud-serviceproviders zoals Apple en ecosysteemplatforms zoals Reincubate.
Mechanismen om deze gegevens te beschermen, hebben een aantal vormen en Apple's staat van dienst bij de implementatie ervan was goed. Dit artikel onderzoekt een aantal technieken die zij - en het team bij Reincubate - hebben gebruikt.
Bewaar minder - indien mogelijk
Ten eerste is het minder lonend om minder dan meer te sparen. Er zijn voorbeelden hiervan waar nooit gegevens in de iCloud zijn opgeslagen, zoals waar gezichtsherkenningsgegevens van Foto's niet in de iCloud-fotobibliotheek zijn opgeslagen, maar lokaal in de cache zijn opgeslagen. Data-artefacten van Apple's HealthKit, HomeKit en TouchID worden op dezelfde manier behandeld, net als Android's lock-screen gezichtsherkenningsgegevens. Dit is natuurlijk vaak een afweging van gemak en de waarde van het synchroniseren van die gegevens tussen apparaten. Sommige systemen gebruiken een gedeeltelijke benadering. IMessage slaat bijvoorbeeld een beperkte hoeveelheid inhoud op in de cloud, maar vertrouwt erop dat andere gegevens direct tussen apparaten worden gesynchroniseerd.
Veilige berichtensystemen zoals Telegram of WhatsApp hebben een heel andere benadering. Omdat er geen gegevens (of ten minste niet veel) op hun servers worden opgeslagen, moet een uitgebreide set gegevens worden opgenomen in elke back-up van een apparaat zodat een gebruiker op een zinvolle manier kan back-uppen en herstellen. In zekere zin, om de veiligheid te behouden, wassen die app-leveranciers hun handen van het beheer van die gegevens en laten ze die over aan de eindgebruiker, die ervoor kiest om lokaal of in de cloud een back-up van hun apparaten te maken.
Er zijn dus twee uitersten, en men kan WhatsApp - met weinig in de cloud en alles in de back-up - contrasteren met Facebook Messenger, die niets opslaat in een back-up van een apparaat, omdat het gemakkelijk beschikbaar is in de cloud en moet in orde zijn voor Facebook om zijn webinterface te bieden.
Er is hier geen juiste oplossing, maar er moet aan worden gedacht: voor het gebruik van een app die deze gegevens host, moet de app-leverancier het veilig beheren, vaak blijven gebruikers in het ongewisse over wat er wordt opgeslagen en hoe. Het gebruik van een app die geen gegevens centraal opslaat, betekent dat de eindgebruiker de verantwoordelijkheid voor de beveiliging van zijn eigen back-upgegevens moet nemen, tenzij deze wordt opgeslagen in de cloud van zijn platform, zoals het geval is met iCloud-back-ups en Google's Android 7.0+ apparaatbackups.
Interessant is dat, zoals in de onderstaande grafiek, sommige app-makers beide uitersten van deze positie innemen. De Snapchat-app slaat bijna al zijn gegevens op in de cloud, terwijl de fysieke extensie van de app - Spectacles - al hun gegevens lokaal op het apparaat bewaart.
Hoewel Breaking Spectacles niet breed worden uitgerold, zijn ze vrij onzeker: door de "snap" -knop zeven seconden ingedrukt te houden, kan een hacker ze koppelen aan een nieuwe telefoon en een van de niet-versleutelde snaps verkrijgen die de rechtmatige eigenaar erop had opgeslagen. Dit staat in schril contrast met de beveiligingsprincipes die zijn aangenomen voor de Apple Watch.
Sterke codering
Dat brengt ons bij de tweede kritische techniek: sterke codering , idealiter met onvolledige opslag van de sleutels. Als gegevens te gevoelig worden geacht om te worden geback-upt op een manier die kan worden gebruikt in het geval dat een apparaat wordt vernietigd of vervangen, zijn er andere technieken die kunnen worden gebruikt. Door gebruik te maken van een specifiek apparaat, maakt de " Secret Conversations " -functie van Facebook gebruik van hardware-identificatoren om inhoud te coderen. Als het apparaat verloren gaat, wordt de inhoud praktisch onherstelbaar.
Sommige systemen maken gebruik van een vergelijkbare techniek waarbij een apparaatspecifieke token kan worden gemaakt om te zorgen dat slechts een beperkt aantal apparaten tegelijkertijd toegang tot inhoud heeft. Snapchat en WhatsApp gebruiken elk een variatie hiervan. Bij het inloggen op Snapchat op een apparaat, wordt een token gemaakt en gedeeld tussen de servers van Snapchat en het apparaat. Als dezelfde gebruiker zich bij een ander apparaat aanmeldt, wordt er een nieuw token gemaakt, dat de eerdere inhoud van de cloud vervangt en het eerste apparaat dwingt zich uit te loggen omdat het geen inkomende berichten kan decoderen. Er is een duidelijke kwetsbaarheid voor deze techniek bij gebruik op onveilige systemen, wat betekent dat het token elders kan worden gekopieerd en gebruikt. Als een argument nodig was waarom het gebruiken van een geroot Android- of gejailbreakt iOS-apparaat een vreselijk idee is, dan is dit het, en het verklaart ook waarom het niet waarschijnlijk is dat er binnenkort een webclient voor Snapchat is.
Hoewel het een ding is om mogelijk geheime Facebook-berichten te verliezen, zijn sommige gegevens zowel zeer gevoelig als zeer waardevol voor de eigenaar ervan. Het lijkt contra-intuïtief, maar als de persoonlijke waarde als de gegevens groot genoeg zijn, wordt het vaak zo opgeslagen dat er veel mogelijke manieren zijn om het te decoderen of te herstellen. Dit verruilt de beveiliging met minder onpraktisch. Er is bijvoorbeeld een groot aantal gegevens gekoppeld aan iCloud- en Google-accounts, waaronder - in beide gevallen - een vorm van gedistribueerde cloud-sleutelhangers die alle wachtwoorden van een gebruiker opslaat. Niet alleen dat, maar Google's promotie van hun accounts als een authenticatiemechanisme op andere sites met OAuth betekent dat het onherroepelijk verliezen van toegang tot accounts als deze een bittere pil zou zijn om te slikken.
Aangezien deze accounts te waardevol worden geacht om gemakkelijk hun permanente verlies te riskeren, wordt een oplossing in het midden gebruikt wanneer gegevens in de cloud worden opgeslagen, maar gecodeerd met een token of wachtwoord dat alleen door de gebruiker wordt bewaard en niet wordt opgeslagen. Dit is de reden waarom, bij het inloggen op een nieuwe installatie van Google's Chrome-browser, de in de cloud opgeslagen wachtwoorden pas beschikbaar zijn nadat een secundair synchronisatiewachtwoord in de browser is ingevoerd.
De coderingsbelasting delen
Apple's Tim Cook - die zowel serieus als fundamenteel gelijk heeft op beveiliging - heeft vorig jaar alleen al bewezen dat ze geloofden in deze techniek:
Al vele jaren gebruiken we codering om de persoonlijke gegevens van onze klanten te beschermen, omdat we denken dat dit de enige manier is om hun gegevens veilig te houden. We hebben zelfs die gegevens buiten ons bereik geplaatst, omdat we geloven dat de inhoud van je iPhone geen van onze zaken is.
- Tim Cook in " Een bericht aan onze klanten "
Afgezien van al het andere, kan dit cloud-providers helpen om te voorkomen dat volledige gebruikersgegevens aan overheidsactoren worden onthuld. Als ze verplicht zijn om het te verstrekken via een bevelschrift, kunnen ze dit doen zonder de gegevens van een gebruiker direct bloot te leggen, omdat de gegevens verder moeten worden gedecodeerd, wat alleen kan worden gedaan met een sleutel die alleen de eindgebruiker heeft.
Soms, zoals in het geval van multi-factor authenticatie (MFA), tweefactorauthenticatie (2FA) of tweestapsverificatie (2SV), betekent dit dat de extra sleutel alleen kan worden verzonden naar of gegenereerd door een bepaald apparaat. Banken en VPN's gebruiken vaak fysieke kaartlezers of beveiligde zaadgeneratoren, die vormen zijn van op tijd gebaseerde eenmalige wachtwoordgenerators (OTP of TOTP). Zowel Google als Apple bieden eenvoudige op SMS gebaseerde MFA en volledige 2FA-systemen, waarbij Google gebruikmaakt van HOTP / OATH en Apple's eigendom is.
Wanneer beveiligings- of wetshandhavingsinstanties (LEA) deze gecodeerde gegevens hebben maar geen eindgebruikerssleutel om deze te decoderen, kunnen ze proberen deze met behulp van krachtige machines bruut te forceren om de gegevens te testen aan de hand van automatisch geraden wachtwoorden. Apple's iOS heeft hier een enorm voordeel ten opzichte van Google's Android: omdat Apple de hardware op hun apparaten nauwgezet bestuurt, kunnen ze encryptietechnieken ontwerpen die alleen hun hardware snel kan uitvoeren en die andere apparaten zoals desktopcomputers traag uitvoeren. Toen Reincubate het eerste bedrijf ter wereld was dat de ontsleuteling van gegevens vanaf 10.2 ondersteunde , was het niet zo dat het bedrijf als eerste moest begrijpen hoe 10.2 werkte - het was dat we de eerste waren om de snelle decodering van de slimme techniek van Apple te schalen. Door elke ontcijferpoging een aantal seconden op conventionele hardware te nemen, werd het onpraktisch voor hackers of LEA om brute kracht te gebruiken.
Beveiliging door onduidelijkheid
Het zou niet goed zijn om deze technieken te herzien zonder er een te bespreken waar Apple het meest goed in is: beveiliging door middel van obscuriteit. Door openbare API's, gedetailleerde documentatie of zelfs communicatie over deze systemen niet vrij te geven, kan het bedrijf voorkomen dat hackers worden gewaarschuwd voor mogelijke aanvalsvectoren. Lange tijd was het argument tegen obscuriteit dat openbaarmaking en Open Source tot betere beveiligingsresultaten leidden, maar dat was vóór de ontdekking van 2014 dat OpenSSL - een kritieke Open Source beveiligingsbibliotheek die vrijwel alles gebruikt - bijna fundamenteel onzeker was en is geweest.
Neem contact op als u manieren wilt verkennen om met app- of cloudgegevens te werken of als u geïnteresseerd bent in een beter begrip van de dynamiek van de verschillende benaderingen.
