Google Cloud Storage gaat alle data versleutelen

Google gaat alle data die opgeslagen wordt bij zijn Cloud Storage-platform standaard versleutelen. Voor de encryptie gebruikt Google de AES-128-standaard, die het ook toepast bij het versleutelen van zijn eigen data.

Gebuikers van het platform hoeven niks te doen om van de functionaliteit gebruik te maken: de servers van Google regelen de versleuteling automatisch. Elk Cloud Storage-object wordt via de AES-128-encryptie versleuteld, en de encryptiesleutels worden op hun beurt ook weer versleuteld met een set master keys die volgens Google regelmatig gewijzigd worden. Google zegt zijn eigen data op eenzelfde manier te versleutelen.

De functionaliteit is momenteel al actief voor alle nieuwe data die weggeschreven wordt. De komende maanden zal Google all bestaande data op het platform migreren en versleutelen. Google adviseert gebruikers die zelf controle willen hebben over hun encryptie om hun data eerst lokaal te versleutelen en daarna pas naar het cloudplatform te uploaden. Concurrent Amazon biedt overigens al langer versleuteling aan voor klanten van zijn cloudopslagdienst S3, en gebruikt daarvoor de zwaardere AES-256-variant.

Reacties (79)

Waarom zou je cloud gebruiken? Zeker met amerikaanse bedrijven. De veiligheidsdiensten daar hebben duidelijk aangegeven dat ze voor buitenlanders 0,0 respect hebben voor privacy.
Echt zo duur zijn externe harde schijven niet en ze zijn ook nog eens niet afhankelijk van het internet of het blijven voortbestaan van het bedrijf. Zie het hele geneuzel met Kim Dotcom.
En als bedrijf moet ik er al helemaal niet aan denken om mijn gegevens aan een 3e partij te geven. (Shell, Phillips etc hebben vast hele leuke dingen op servers staan)

Waarom zou je de cloud gebruiken? Je reageer op een nieuwsbericht, omdat je de cloud niet wilt gebruiken. Je hebt je reactie zojuist in de cloud gezet, gefeliciteerd!

Heel internet is cloud, cloud is tegenwoordig gewoon de communicatie tussen client en server en alle data die daarover heen gaat.

Waarom zou je de auto pakken, waarom zou je naar buiten lopen, waarom zou je de trein nemen als er zoveel ongelukken gebeuren, waarom zou je nog op vakantie gaan?

Ga je nou echt een berichtje op tweakers vergelijken met bv gevoelige bedrijfsdata? Of gewoon je eigen privedata. Bij het offline halen van megaupload waren er toch talloze mensen die ineens "hun" data kwijt waren. Omdat ze zo dom waren om volledig op de cloud te vertrouwen. (met je kop in de wolken lopen vind ik hier wel heel erg van toepassing). Punt van mijn verhaal is dat op het moment dat je volledig op de cloud vertrouwd je ook de controle erover weggeeft. Dat mijn berichtjes op tweakers in rook opgaan, boeit me niet. Zelfde geldt voor mijn facebook account. Maar de backup van mijn foto`s boeit me wel. En die regel ik dus zelf. Staat op 3 verschillende pc`s, 1x een externe hdd en daarnaast word het ook nog op dvd gezet. En waarom? omdat ik al 1x heb meegemaakt dat 3 harde schijven binnen een week kapot gingen. Google hoeft maar 1x op de manier van megaupload onderuit te gaan en je bent alles kwijt. Verder kan ik ook niet controleren wie/wat er allemaal in loopt te neuzen. Dus nee, ik ben niet in principe tegen cloud, ,maar voor sommige dingen zijn er in mijn ogen betere alternatieven.

Heel even rustig aan, ik heb nooit een bedoeling gehad om onrust te verwekken. Het enige wat ik je wil vertellen is dat je vanalles kan ontduiken, maar wat heeft dit voor nut?
Als veiligheidsdiensten en hackers vanalles van je willen weten kan je het moeilijker maken om erachter te komen, maar ze komen er toch wel achter. Het leven zit vool risico's. De enige manier om deze risico's niet te lopen is door de risico's kleiner te maken.

Omdat cloud slechts een nieuwe term is maar al heel lang bestaat. Alles wat je centraal opslaat aan gegevens en benaderbaar is via de web, bestaat al zo lang.

Yeah, right! Als het voor organisaties als NSA is bedoeld heeft dit geen enkele zin.

Zolang ze zelf de masterkeys hebben, kunnen governmentele organisaties er dus ook gewoon bij. Patriot Act kan namelijk alle instanties die zaken doen met de VS (dus ook organisaties die niet in de VS zijn gevestigd) dwingen om de keys af te staan! Velen van ons beseffen niet hoe ver dit gaat.

Beste methode is nog steeds: eerst zelf sterk versleutelen en dan pas uploaden naar de cloud.

Exact. Overigens zijn er al diensten die dat beloven te doen. SpiderOak en Wuala stellen allebei dat de sleutels alleen bij de gebruiker bekend zijn.

Zelf zit ik te wachten doe ownCloud client-side encryptie gaat ondersteunen zodat ik het volledige verhaal in eigen handen kan houden.

Of helemaal niet meer uploaden naar de cloud. Gewoon op je eigen HDD met je eigen backup.

Eindelijk, en nee, data gaat niet onversleuteld over het lijntje, dat noemen we SSL! SSL is in praktijk een manier om data te encrypten via assymetrische cryptografie. Hoewel SSL natuurlijk niet altijd garantie geeft dat het onkraakbaar is, daarom testen ze het ook eerst lokaal.

Ik heb hier zo verschrikkelijk lang op gewacht, ook omdat ik hetzelfde heb gedaan met mijn systeem, geschreven in PHP. Daar gebruik ik net als Amazone AES-256, alleen niet dezelfde 'zware' versie.

Bestandsencrypties zijn een belangrijk onderdeel van de IT. Als de politie langs komt, om bestanden op te halen, kan Google nu alleen maar de versies met encryptie geven!

Maar zoals altijd: je hebt altijd een goed wachtwoord nodig! De mens is de zwakste schakel in de beveiliging. Als je geen goed wachtwoord hebt, en het wordt geraden, zijn bestandsencrypties zwaar nutteloos (op dat moment dan).

[Reactie gewijzigd door Amanush op 17 augustus 2013 14:55]

SSL/TLS is grotendeels symmetrisch. In de assymmetrische fase aan het begin wordt alleen de sessie sleutel uitegewisseld. In het algemeen wordt die sessie sleutel via het netwerk uitgewisseld wat het risico wel groter maakt.

Nu is het nog niet mogelijk om de sessie sleutel te verkrijgen (zonder de private key van de server), maar dat kan ooit wel het geval zijn. Daarom is het beter om PFS (http://en.wikipedia.org/wiki/Perfect_forward_secrecy) te gebruiken waarbij de sessie sleutel niet over de lijn gaat en dus ook niet door een man-in-the-middle kan worden opgeslagen. Zover ik weet is Google een van de weinige partijen die PFS al gebruikt...

Ik zou sowieso je data versleutelen als je het in een cloud wilt opslaan...

Maar hoe veilig is SSL?

SSL (tegenwoordig officieel TLSv1.0) is best veilig. Het probleem zit hem in het Public Key Infrastructure (PKI), wat een onderdeel omvat van SSL/TLS. Het PKI verzorgt de initiële communicatie tussen de client en de server, waaronder bijvoorbeeld het afspreken van een symetrische sleutel valt.

Het probleem dat het PKI heeft is dat wij de certificaten van de server verifiëren met een digitale handtekening van een zogenaamd rootcertificaat. Deze rootcertificaten worden beheerd door bedrijven zoals VeriSign, Comodo, of tot twee jaar terug DigiNotar. De functie van deze bedrijven is de validiteit van handtekening aanvragen verifiëren. Klinkt in eerste instantie prima, toch?

Maar stel dat een drieletterige organisatie in de VS een kopie van een rootcertificaat heeft, die organisatie zou nu in het geheim nepcertificaten kunnen ondertekenen met een echte handtekening. De nepcertificaten zouden vervolgens gebruikt kunnen worden om een Man-in-the-Middle (MITM) aanval uit te kunnen voeren.

Het probleem is dat wij grote bedrijven vertrouwen om de identiteit van servers te waarborgen.

[Reactie gewijzigd door TheBigB86 op 17 augustus 2013 15:15]

SSL is volgens mij kraakbaar, maar het is iets veiliger. Het maakt ook uit wat voor certificaat je hebt en dergelijke. Op SSL kan een man-in-the-middle attack worden uitgevoerd, het is niet 100% waterdicht. Het is wel een extraatje qua beveiliging!

[Reactie gewijzigd door Amanush op 17 augustus 2013 14:50]

In veel landen bestaat er wel zoiets als een decryptieplicht, dus als de politie met het juiste bevel komt dan moeten ze het gewoon ontsleutelen. Hier in Nederland hebben/krijgen we dat bijvoorbeeld ook gewoon. En Google moet daar ook aan voldoen denk ik.

Ontsleutelplicht is wellicht in strijd met mensenrechtenverdrag

in Nederland hebben we dat juist nog niet, alhoewel Opstelten het graag wel zo zou zien.

Wel een gevaarlijke ontwikkeling wat mij betreft, het gaat namelijk volledig in tegen het principe dat je als verdachte niet gehouden bent bewijs tegen jezelf te leveren.

Daarnaast zou zo'n decryptie plicht niet werken: wat is de sanctie als iemand niet meewerkt? Wanneer mag het toegepast worden? Welke eisen zijn er aan de verdenkingen?

Een persoon die bijvoorbeeld voor terrorisme verdacht wordt zou natuurlijk nooit meewerken als dat ervoor zorgt dat er geen bewijs wordt geleverd voor zijn activiteiten, hij kan dan niet veroordeeld worden voor terrorisme. Iedere sanctie die echter hoger zou zijn dan zijn mogelijke straf voor terrorisme zou hem wel motiveren maar zou m.i. juist weer een veel te groot middel zijn in verhouding tot de rechten van het individu

Wat is er gevaarlijk aan?

Als een verdachte schuldig is dan zal die weigeren gegevens af te staan, die regeling slaat in dat geval nergens op.

Als een verdachte onschuldig is dan kunnen die gegevens wellicht zijn onschuld bewijzen dan wil je juist dat ze die gegevens hebben.

Kortom de regeling is alleen om juist de verkeerde persoon te beschermen.

Het punt is nou net dat als je onschuldig bent er geen bewijs is dat je schuldig maakt, dus waarom zou je dan zelf moeten bewijzen dat je oneschuldig bent?

Nee maar kan je wel gegevens afstaan waaruit kan blijken je onschuldig bent zodat men niet hun tijd verdoet achter de verkeerde mensen aan te zitten.
Normaliter noemen we dat gewoon meewerken aan het onderzoek.

Ik ben me er niet van bewust iets fout te doen, maar heb wel alles te verbergen. Dat heet -privacy-. En daar ben ik erg op gestelt.

Iedereen moet aan het decryptieplicht voldoen, maar dan moet je wel de key hebben. Het is heel makkelijk om de gebruiker de enige te maken die de key in handen heeft.. Bijvoorbeeld via het wachtwoord waar de gebruiker mee inlogt, alleen de gebruiker weet die.
Overigens valt het wel makkelijk af te luisteren.

[Reactie gewijzigd door Amanush op 17 augustus 2013 15:26]

In de voorwaarden van Google drive stond toch dat alles wat je op GD zet, eigendom van Google wordt? Als het van hen is, zullen ze het ook wel makkelijk kunnen decrypten en als het moet, ongecrypt aan de nsa of whatever kunnen geven.

Uhh, nee. Dat doen ze vermoedelijk niet. Want als ze het kunnen decrypten, is encrypten nutteloos. Want wat zij kunnen decrypten kunnen andere partijen zoals terroristen en hackers ook decrypten. In dat geval heeft encrypten totaal geen nut meer.

Hoe decrypten ze de data dan?? Heel makkelijk: vermoedelijk met het wachtwoord van de actieve gebruiker! Maar de enige manier om het te decrypten met dit wachtwoord is een keylogger of iets anders wat 't wachtwoord afluisterd. Dit kan zowel clientside als serverside.

Met die theorie van jou is dit alleen maar een publieksstunt!

[Reactie gewijzigd door Amanush op 17 augustus 2013 15:19]

Ik maak nergens uit het artikel op dat de data versleuteld binnen komt bij google, slechts dat google vanaf nu de storage backend versleuteld, nergens wordt vermeld wie de sleutels in beheer heeft.

Het zou dus heel erg goed wel een stunt kunnen zijn om het image van google te verbeteren.

Zelfs al zou het zijn dat google encrypt aan de hand van het userpassword gebeurd dit pas bij google zelf, 1 simpel bevel van de NSA en google zal alsnog alle data overhandigen op het moment dat jij inlogt. (zie bijvoorbeeld hushmail!)

Data komt versleuteld aan bij Google, (SSL), dat is het enige wat ik beweer als het gaat om data die bij Google aankomt. Ja, dit doet Google zelf, daar heb je een punt, en ja, het is heel makkelijk voor Google om dit password te krijgen. Ook daar heb je een punt.

Uhh, nee. Dat doen ze niet. Want als ze het kunnen decrypten, is encrypten nutteloos. Want wat zij kunnen decrypten kunnen andere partijen zoals terroristen en hackers ook decrypten. In dat geval heeft encrypten totaal geen nut meer.

Hoe decrypten ze de data dan?? Heel makkelijk: vermoedelijk met het wachtwoord van de actieve gebruiker! Maar de enige manier om het te decrypten met dit wachtwoord is een keylogger of iets anders wat 't wachtwoord afluisterd. Dit kan zowel clientside als serverside.

Met die theorie van jou is dit alleen maar een publieksstunt!

Je decrypt data met behulp van een sleutel...

Zo gaat het tenminste met AES-128.

Ja, maar deze sleutel is bijna altijd tijdelijk opgeslagen, bijvoorbeeld een wachwoord gehashed met SHA512, in een sessievariabele. Deze kun je dan bijvoorbeeld alleen krijgen bij het inloggen en niet uit een database of via een andere manier van permanent opslaan van data.
Het effect hiervan is, is zodra er wordt uitgelogd de key weg is, tot er weer wordt ingelogd.

Dan weet zelfs Google de key niet, ik weet alleen niet of ze het op die manier doen.

En waar denk je dat de hash-sleutel bewaard wordt?
Die hash sleutel sla je juist op in de database, in tegenstelling tot encryptie kan je het niet decoderen met een sleutel, alleen maar valideren of het ingevoerde wachtwoord klopt. Deze zal je ook nooit naar de client-side doorsteuren maar altijd aan de server-side houden.

Encrypted data staat hier geheel los van.

[Reactie gewijzigd door BoringDay op 17 augustus 2013 20:10]

Niet precies, want je kan ook een hash sleutel gebruiken om data mee te encrypten en decrypten, en diezelfde sleutel telkens weer genereren bij het inloggen. Waarom hashen? Hashen kost tijd, het maak ook meestal de key langer en gooit er tekens in die geen patroon vertonen. Een key zonder patroon is per definitie veiliger en je kan het niet meer kraken door middel van een table met zwakke en minder zwakke wachtwoorden.
Het valideren van wachtwoorden staat hier geheel los van, aangezien je hashes voor meer dingen kan gebruiken.

[Reactie gewijzigd door Amanush op 18 augustus 2013 09:30]

Ik zou nooit een hash key die voor wachtwoorden wordt toegepast gebruiken voor encryptie/decryptie. Dit omdat dan de hash key aan de client side bekend moet zijn en dat is iets wat je niet moet willen.
Wellicht is het dan beter een 2e hash key te laten genereren en die voor data encryptie gebruiken.

Ik streep wel de onzin door, van jouw bericht:

Ik zou nooit een hash key die voor wachtwoorden wordt toegepast gebruiken voor encryptie/decryptie. Dit omdat dan de hash key aan de client side bekend moet zijn en dat is iets wat je niet moet willen.
Wellicht is het dan beter een 2e hash key te laten genereren en die voor data encryptie gebruiken.

Je kan tegenwoordig ook serverside encrypten, hoor.. Toevallig doet Google dat ook. Bij het inloggen wordt het wachtwoord naar Google gestuurd en daarmee kan geencrypt worden, na het valideren van het wachtwoord.
Gehashed, of zonder hash, als het maar op een veilige manier gebeurd. Bij hashes heb je geen patroon, dus als je het hashed heb je een relatief veilig systeem. Het valideren van een wachtwoord staat hier los aan, aangezien je een hash genereert na het valideren door middel van het plain password die via een POST naar de server is gestuurd door op het knopje 'inloggen' te drukken. Wat ik telkens zeg en jij eindelijk begint te begrijpen: extra SHA/MD5 hash voor encrypten van bestanden scheelt al een heel stuk.

[Reactie gewijzigd door Amanush op 18 augustus 2013 14:15]

Dat ligt er geheel aan als jij je webpagina genereert aan de server kant dan kan je het idd serverside decrypten.

Aangezien ik veel met javascript werk waarbij dom-objecten worden opgesteld op basis van de aangeleverde data dan dien je dit clientside te regelen.

En volgens mij moet je tegenwoordig niet meer standaard SHA/MD5 hashes gebruiken omdat ze niet veilig zijn.

SSL is een begin, grote nadeel van SSL is dat het aan de andere kant van het lijntje (of ergens onderweg, in geval van een man-in-the-middle aanval) weer gedecrypt wordt. Wat je eigenlijk zou willen, is encryptie en decryptie alleen op de client zodat de data over het hele pad en in de storage zelf encrypted is. Ik meen dat Mega zo werkt.

Dat is een nadeel van veel protocollen, man-in-the-middle kan ook worden toegepast op SSL, inderdaad. Daarom denk ik dan Google naast SSL ook andere protocollen gaat gebruiken

SSL is kraakbaar. Google kan altijd bij je data aangezien het hun encryptie is, met hun hash op hun machine, dus ze kunnen je data gewoon doorgeven. Daarnaast als de server aan staat heb je niks aan encryptie want de bestanden staan toch al ingelezen in het geheugen en dergelijke. Het zou enkel werken met losse encrypted containers die enkel worden geopend wanneer je ze benaderd, en dan zijn ze nog op dat moment uit te lezen. Dit zie ik echter nergens dus heb je er helemaal niks aan.

[Reactie gewijzigd door Freedox op 17 augustus 2013 14:53]

Dat ontken ik niet, met een man-in-the-middle-attack heb je het al gekraakt, namelijk.
Het feit dat je hier niks aan hebt, bekritiseer ik ten zeerste.

De IT is nooit waterdicht, maar elke stap is een enorme vooruitgang, hoewel alles in de IT te kraken is.

Of ze een key voor henzelf of NSA bewaren, is nergens op gebaseerd. De bewering dat dit niet zo is, is ook nergens op gebaseerd. Dat weten we niet en kunnen we (nu) niet vaststellen!

[Reactie gewijzigd door Amanush op 17 augustus 2013 15:20]

Dit is dus compleet zinloos, de enige beveiliging die dit biedt is als iemand fysiek de server heeft, dan kan hij niet bij je data. Als mensen toegang tot je account hebben krijgen ze gewoon de gedecrypte files voorgeschoteld.

Als je niet wilt dat mensen bij je data kunnen, sla het dan al helemaal niet op "in de cloud" er word altijd zo makkelijk gedaan over je data zomaar afstaan aan derden, maar achteraf als er iets negatiefs (snowden etc.) naar buiten komt is iedereen op zijn teentjes getrapt. als je wilt dat je data veiliger is opgeslagen op een server dan kun je het beter zelf versleutelen en daarna versturen.

Als mensen toegang hebben tot je account, dan krijgen ze uiteraard de gedecrypte files voorgeschoteld, want dan zijn ze jou.

De echte reden waarom dit niet zo heel veel toevoegt (en dat geeft Google zelf ook aan met hun advies in de laatste alinea) is dat de data nog steeds onversleuteld over de lijn gaat. De NSA kan dus nog steeds meeluisteren.

Ter verduidelijking:

Jouw computer (C) > internet (I) > Google (G) > Storage (S)

Zover ik weet was alleen I versleuteld met HTTPS bij Google. Nu hebben ze dus ook S versleuteld. Over C heeft Google geen invloed (m.u.v. Chrome OS en Android). En G, Google zelf dus, is nog steeds de zwakste schakel. Tenminste als het om politiek en NSA -achtige dingen gaat.

Dus inderdaad, wat onleesbaar G passeert kan de NSA niet lezen via G.

Ik denk dat I (HTTPS) of C (client/computer) de zwakste schakel is. Google die encrypt het gewoon weer en de enige manier om dat te kraken is door de code te veranderen van het encrypten en daar een soort lek in te prikken.

Bij HTTPS/SSL kan er een man-in-the-middle attack plaatsvinden en bij C is een Trojan of Keylogger al genoeg, in geval van schadelijk voor virussen.

Overigens hebben ze op C wel degelijk invloed. Javascript draait client-side. Dus als je het encrypt met Javascript en decrypt met serverside code, heb je dat ook gedekt. Wordt het veiliger? Nee!

[Reactie gewijzigd door Amanush op 17 augustus 2013 15:00]

Overigens hebben ze op C wel degelijk invloed. Javascript draait client-side. Dus als je het encrypt met Javascript en decrypt met serverside code, heb je dat ook gedekt. Wordt het veiliger? Nee!

Je moet het ook encrypten op de client, en ook weer decrypten op de client. Dan is het wel een stuk veiliger.

Edit: de reden dat Google dat niet doet is dat ze dan geen targeted ads meer kunnen serveren (ze kunnen immers jouw data niet meer lezen) en er niets meer aan je data te verdienen valt...

[Reactie gewijzigd door Anoniem: 415197 op 17 augustus 2013 15:15]

Not true, want je hebt geen manier om veilig data aan te pakken, de enige manier is javascript, en dat is totaal niet veilig om mee te encrypten en mee te decrypten.
Javascript is kraakbaar. Ik bekijk de broncode van een webpage en ik ben achter alle keys die ik nodig heb voor decryptie.. Het voegt niks toe, of je het nou encrypt en decrypt met Javascript, of alleen encrypt met javascript en serverside decrypt met bijvoorbeeld PHP. De keys zijn af te kijken, dan is het encrypten met de client en decrypten met de server zelfs nog veiliger dan encrypten en decrypten met javascript

Tenzij je je data handmatig encrypt en decrypt, natuurlijk! Verder is er bijna geen manier om dit automatisch te doen met de software die Google open voor gebruik stelt.

[Reactie gewijzigd door Amanush op 17 augustus 2013 16:59]

Je vergeet 1 ding: met Javascript hoef je de sleutel niet van de server te krijgen, die kan je uit local storage halen, of die kan de gebruiker moeten invoeren om de data te kunnen zien. In dat kan een man in the middle nog helemaal niets, en Google ook niet.

Het risico blijft alleen dat als het (client side) encryptie script van de Google servers afkomstig is er nog altijd een kans bestaat dat ze door de NSA e.d. verplicht worden een achterdeurtje in te bouwen dat de key alsnog doorsluist naar de instanties op het moment dat deze client side in wordt gevoerd. Als je 3rd party software gebruikt om de data te encrypten voordat deze verstuurd wordt naar Google heb je dat risico niet, tenzij er natuurlijk een keylogger of zo op je systeem draait. Als alleen een NSA POI eenmalig een dergelijke aangepaste versie van een client side encryptie script krijgt kan het nog wel eens een lang duren voordat duidelijk wordt dat er van deze methode gebruik gemaakt wordt.

[Reactie gewijzigd door Tribits op 17 augustus 2013 23:56]

Bij HTTPS/SSL kan er een man-in-the-middle attack plaatsvinden (...)

Eigenlijk is HTTPS juist zo ontworpen dat dat niet kan. Een vrij goede uitleg wordt hier gegeven (wel in het Engels). Inderdaad moet ik wel de kanttekening maken (wordt ook in de bron gezegd) dat gebruikers waarschuwingen vaak weg klikken.

Ik vind het redelijk naïef om in deze tijden nog te denken dat google geen key achterhoud voor de NSA.

Dat is precies wat ik bedoel met dat Google nog steeds de zwakste schakel is. Techneuten zijn snel geneigd veiligheid uit te leggen in technische termen. Helaas heb je ook te maken met mensen, bedrijven, politiek en vertrouwen in ons begrip van de natuur en de wiskundige modellen daarvan.

Neem dit voorbeeld. Je wilt iets beveiligen waar een machtige partij (M) bij wilt komen. Stel je gebruikt Google Drive (D). Even aangenomen dat C goed beveiligd is. Hoe groter M, hoe makkelijker G buigt. Uiteindelijk heeft M weinig invloed op technische zaken, natuurwetten kan M ongeacht M's grote niet veranderen. De kans dat M Google sommeert de inhoud van D te tonen groter is dan dat ze de encryptie proberen te breken. En als M zich manifesteert als de NSA et voila reality!

Dat is precies wat ik bedoel met dat Google nog steeds de zwakste schakel is. Techneuten zijn snel geneigd veiligheid uit te leggen in technische termen. Helaas heb je ook te maken met mensen, bedrijven, politiek en vertrouwen in ons begrip van de natuur en de wiskundige modellen daarvan.

Neem dit voorbeeld. Je wilt iets beveiligen waar een machtige partij (M) bij wilt komen. Stel je gebruikt Google Drive (D). Even aangenomen dat C goed beveiligd is. Hoe groter M, hoe makkelijker G buigt. Uiteindelijk heeft M weinig invloed op technische zaken, natuurwetten kan M ongeacht M's grote niet veranderen. De kans dat M Google sommeert de inhoud van D te tonen groter is dan dat ze de encryptie proberen te breken. En als M zich manifesteert als de NSA et voila reality!

Is het alfabet nog niet op ...

iedereen die bold zijn punt wil halen ...

Sowieso is het redelijk naïef om te denken dat als je ook maar iets online zet dat het 100% veilig is. Dat is gewoon nooit zo. Alles is uiteindelijk te kraken en om te denken dat de NSA de enige is die meekijkt, is ook redelijk naïef imho

Het is best veilig te maken hoor, kijk maar eens hoe deze backupservice in elkaar zit:
https://www.tarsnap.com

De encryption keys verlaten de client nooit en de client is open source, dat is de enige manier om iets veilig te kunnen uploaden.

Ik heb tarsnap een enkele jaren gebruikt. Ik ben ermee gestopt omdat het is zo ontzettend traag bij het terughalen van bestanden uit een archief dat het onbruikbaar is.

[wrongtopic]

[Reactie gewijzigd door Anoniem: 470811 op 17 augustus 2013 22:40]

De echte reden waarom dit niet zoveel toevoegd is dat je niet zelf je sleutels kan beheren.
Als de NSA hard stilletjes op Google's deur bonkt en de sleutels van Google in handen krijgt, hebben ze overal toegang toe.
Ik lees in een ander artikel dat ze er wel over nadenken om gebruikers hun eigen sleutels te laten beheren.
Maar als die master keys ook gewoon op een Google server staan dan zou de NSA er nog gewoon theoretisch bij kunnen en gewoon al je data kunnen ontcijferen met je eigen masterkey.

[Reactie gewijzigd door -=bas=- op 17 augustus 2013 15:17]

Ik lees in een ander artikel dat ze er wel over nadenken om gebruikers hun eigen sleutels te laten beheren.
Maar als die master keys ook gewoon op een Google server staan dan zou de NSA er nog gewoon theoretisch bij kunnen en gewoon al je data kunnen ontcijferen met je eigen masterkey.

Op zich kan je dat oplossen door per gebruiker een key te genereren en die key weer te encrypten met een key die afgeleid is van het wachtwoord. Dat voorkomt dat de instanties je data kunnen decrypten met de sleutels die bij Google beschikbaar zijn en heeft als voordeel dat je je wachtwoord nog kunt wijzigen zonder de noodzaak alle data opnieuw te encrypten.

Het voorkomt niet dat de NSA Google kan verplichten een achterdeurtje in te bouwen dat de key doorsluist op het moment dat jij je aanmeldt op de server van Google. Dat is gewoon inherent aan server side encryptie, dus nooit echt veilig, ook niet als je client side de sleutels beheert. De enige manier om dat op te lossen is gebruik maken van client side encryptie software uit een onafhankelijke/betrouwbare bron (i.e. open source verstrekt/gecompileerd door een bron die niet door de NSA te beinvloeden is).

Het nadeel daarvan is dat wanneer de gebruiker zijn wachtwoord vergeet de bestanden niet meer te ontcijferen zijn.

Tenzij je deze encrypt met antwoorden van beveiligingsvragen en opslaat in een database, natuurlijk..

Waar ik daarmee op doel is dat ze ook encryptie hadden kunnen aanbieden waarbij je zelf de sleutel kon kiezen en dat er bij een gehackt account dus nog niets aan de hand is.

Als mensen toegang tot je account hebben krijgen ze gewoon de gedecrypte files voorgeschoteld.

En daarom biedt Google al enige tijd de mogelijkheid two-factor authentication aan te zetten zodat het een stuk moeilijker wordt voor anderen om toegang te krijgen tot je account. Na ssl-enctryptie voor het verkeer en two-factor authenticatie is dit de logsiche volgende stap om google accounts veiliger te maken.

Daarom doet men er nog wel verstandig aan om het te encrypten mocht er op de server ingebroken dan liggen de gegevens niet open en bloot.

Weet men in te loggen op je account dan gaat het maar om 1 gebruiker, hacken ze de server dan gaat het om een hele groep gebruikers.

Dit niet zozeer om veiligheidsdiensten of politie te dwarsbomen maar om gebruikers te beschermen tegen kwaadaardige hackers die ook werkelijk je gegevens zullen misbruiken.

[Reactie gewijzigd door BoringDay op 17 augustus 2013 15:13]

Hetzelfde als dat jij je harde schijf encrypt, maar ze hebben je wachtwoord. Dan kunnen ze nog steeds bij je files...

Gebuikers van het platform hoeven niks te doen om van de functionaliteit gebruik te maken: de servers van Google regelen de versleuteling automatisch

Hier moest ik even lachen.

Goolge doet de encryptie en heeft de sleutels. Dus de NSA heeft ze ook.
Wat een schijnvertoning. Dit is puur voor de vorm.


Wil je veiligheid, dan zul je het zelf in de hand moeten houden. Dat kost wat moeite ja.

[...]

Wil je veiligheid, dan zul je het zelf in de hand moeten houden. Dat kost wat moeite ja.

Dat geeft Google zelf ook aan door te zeggen dat je je data zelf moet versleutelen, voordat je het in hun cloud zet.

Het zou ze wel sieren als ze een optie zouden aanbieden om je zelf de sleutel te laten beheren, zoals Mega dat ook doet.

Het bestand dat je in de cloud plaatst zelf encrypten en dan uploaden, na downloaden decrypten.

Als je dit zelf doet, handmatig, is dit misschien wel de veiligste manier om met je data om te gaan als je het in de cloud wilt hebben.

ben het met de 1e opmerking eens, Google HD encryptie is alleen van belang voor de data in het datacenter.
Op het moment da je ingelogd bent is het met SSL beveiligd maar dat is sessie encryptie en staat los van deze vorm van encryptie, en was dus al het geval.

je data in de google/amazon cloud ? .. is gewoon overdragen aan de NSA.. simpel.
sla het maar op je zelfbouw server op .. met een betere encryptie

Google adviseert gebruikers die zelf controle willen hebben over hun encryptie om hun data eerst lokaal te versleutelen en daarna pas naar het cloudplatform te uploaden.

Het siert Google dat ze het enige advies om veilig met data om te gaan niet achterhouden. Jij bent degene met het grootste belang erbij dat de data niet bekend wordt -- dan moet jij ook verantwoordelijk zijn voor de beveiliging ervan. Natuurlijk heeft Google er ook wel belang bij (weinig klanten meer over als het duidelijk is dat alles op straat kan komen) maar nog steeds niet het meeste belang.

Ik ben niet bepaald staatsgevaarlijk, maar ik heb in principe geen trek om mee te werken aan data mining experimenten van geheime diensten. Ik ben dol op Dropbox, maar niet zonder cryptfs.

Als of encryptie iets uitmaakt bij Google, Microsoft of welke andere US cloud provider dan ook....
Ze kunnen AES128/AES256/AES4048/... whatever bieden, zolang ze de keys aan NSA geven is het schijn veiligheid.
Ik denk dat US-based cloud providers het erg moeilijk gaan krijgen in de toekomst.