Data encrypted opslaan, kunnen delen, zonder duplicatie

[ZpAz]

Dag luitjes,

Zoals once again loop ik weer eens met een hersenspinsel rond in mijn hoofd voor een project. Een systeem waar data opgeslagen wordt.

Hierin zijn er projecten waarin de bestanden staan. Vergelijkbaar met mappen. Een project kan meerdere mensen hebben die hier toegang tot hebben (via uitnodiging).

Dit systeem heeft de volgende eisen:

1. Encrypted opslaan bestanden
2. Duplicatie in data voorkomen (minder opslag ruimte, sneller uploaden van gelijke bestanden)
3. Mogelijkheid om de data te delen met andere gebruikers van de service
4. Ik / medewerkers moeten geen toegang hebben tot de un-encrypte data

Maar ik kom er niet uit, volgens mij bijten deze eisen elkaar. (vooral nummertje 2)

Nu had ik het idee als volgt in mijn hoofd.

Encryptie
Elk bestand wat upgeload wordt ge-encrypt met een unieke key per project per lid. Deze key wordt dus per project gemaakt op het moment dat het project wordt aangemaakt. Deze key wordt ge-encrypt met het wachtwoord van de eigenaar. In dit geval hoef ik enkel de keys per file opnieuw te encrypten mocht de persoon zijn wachtwoord wijzigen.

Dit wachtwoord wordt uiteraard gehashed opgeslagen. Hierdoor kan ik dus niet bij de data van de gebruiker komen, immers weet ik het wachtwoord niet waarmee de key is ge-encrypted.

Wanneer de gebruiker inlogt wordt in zijn sessie elke key van zijn bestanden gedecrypt met zijn wachtwoord. Hierdoor kan hij dan de bestanden via deze key decrypten. Is de sessie verlopen worden deze keys weer uit het geheugen verwijderd.

Hierdoor kan ik theoretisch niet bij de data van de gebruiker, right? - Enkel op het moment dat de gebruiker in is gelogd zijn de keys immers beschikbaar -

Bestanden delen
In dit systeem kan je iemand anders uitnodigen voor het project, dit zal dan via een mail gaan alla: "Jantje nodigt je uit voor 'project-x'. Aangezien de gebruiker die op dat moment uitnodigt is de key voor het decrypten van dat project op dat moment bekend. Dit wordt dan in het mailtje verstuurd samen met het project-id. - Hier is dus ook de key dus ook tijdelijk bekend -

Wanneer iemand accepteerd wordt een voor deze persoon ook de key geencrypted met zijn wachtwoord en opgeslagen. Als er dus een project is met twee leden zijn de keys dus voor elke persoon encrypted opgeslagen met hun eigen wachtwoord.

Probleem
Volgens mij heb ik hiermee de punten 1,2 en 4 getackled, enkel op het moment dat iemand is ingelogd is voor het systeem de key bekend en wanneer iemand wordt uitgenodigd voor het project per e-mail. Volgens mij is daar weinig aan te doen? Of heeft iemand daar een geniale oplossing voor.

Dan zit ik nog met het dubbel opslaan om ruimte te besparen. Iets wat dropbox dus ook toepast, maar dan op een manier dat ze toegang hebben tot de un-encrypted data via een master-key. Maar volgens mij is dat ook niet anders mogelijk, en bijten de encryptie-eisen en het niet duplicaat opslaan elkaar.

Het zou bijvoorbeeld mogelijk zijn om een hash van het originele bestand op te slaan, dan zou ik kunnen herkennen dat een bestand dubbel is. Maar ik zou dat bestand niet kunnen gebruiken voor een andere user omdat ik niet de mogelijkheid heb om het bestand te decrypten. Dat lijkt me dus ook niet werken.

Ik vroeg me af, is dit eigenlijk wel mogelijk of zijn dit gewoon 4 punten die elkaar bijten. Misschien heeft iemand een geniale oplossing voor dit probleem.

[bwerg]

enkel op het moment dat iemand is ingelogd is voor het systeem de key bekend en wanneer iemand wordt uitgenodigd voor het project per e-mail.

De key in de mail ook gewoon versleuteld versturen? Of bedoel je het niet zo? Gewoon met een public key van diegene. Dat het diegene zelf de key krijgt lijkt me vrij logisch, hij moet immers bij de onversleutelde bestanden komen.

Het zou bijvoorbeeld mogelijk zijn om een hash van het originele bestand op te slaan, dan zou ik kunnen herkennen dat een bestand dubbel is. Maar ik zou dat bestand niet kunnen gebruiken voor een andere user omdat ik niet de mogelijkheid heb om het bestand te decrypten. Dat lijkt me dus ook niet werken.

Nee, als het systeem de key niet heeft dan kan het systeem het niet voor je delen, zo simpel is het. Maar eh, waarom niet à la dropbox, gewoon met wachtwoord inloggen, en op basis daarvan toegang tot bepaalde bestanden geven? Dan kun je gemakkelijk maken dat je bestanden kan delen. Als het gevoelige data is zul je dan natuurlijk wel moeten zorgen dat men niet zonder toestemming op het systeem kan, maar een autorisatie-probleem moet je toch al oplossen.

Nu krijg je ook leuke effecten als "wachtwoord weg, data weg". Niet echt fool-proof, afhankelijk van het type gebruiker.

[ACM]

E.e.a. is in ieder geval lastig te combineren op het moment dat je encryptie met deduplicatie wilt uitvoeren

Jouw oplossing leent zich wel voor duplicaat-vrij delen van hetzelfde bestand, met dezelfde encryptie-key, maar elke andere vorm van deduplication wordt heel eng op het moment dat je daar lokaal iets bijzonders mee gaat proberen. Je reduceert tenslotte allerlei stukken randomization en voert bovendien extra kennis over bestanden toe aan je systeem door er op meerdere manieren naar te verwijzen.

Als je het echt heel nodig hebt, zou je kunnen kijken of je een of meerdere checksums van je bestanden kan maken. Mocht je van een nieuw bestand dezelfde checksum tegenkomen, dan weet je in ieder geval dat je een duplicaat hebt. Je hoeft natuurlijk niet per se direct de duplicaten te verwijderen, dat kan ook later gebeuren. Uiteindelijk kan je dan in een situatie terechtkomen waarbij je de bestanden dan kunt behandelen alsof ze gedeeld waren.

Als je de keys versleuteld via asymetrische encryptie, kan je de versleutel-kant van iedere gebruiker wel gewoon op je server bewaren. Dan kan je achteraf alsnog een bekend geworden key versleutelen op naam van alle duplicaateigenaren, zonder dat je hun wachtwoord hoeft te weten.
In dat geval kan je bij het uploaden van het duplicaat de oude file verwijderen en de nieuwe ontsleutelkey bij zowel de oude als nieuwe gebruiker opslaan.

[ZpAz]

bwerg schreef op zondag 02 december 2012 @ 21:43:
[...]

De key in de mail ook gewoon versleuteld versturen? Of bedoel je het niet zo? Gewoon met een public key van diegene. Dat het diegene zelf de key krijgt lijkt me vrij logisch, hij moet immers bij de onversleutelde bestanden komen.

De key is op dat moment versleuteld met het wachtwoord van degene die uitnodigt. Degene die uitgenodigd wordt heeft immers dan even toegang tot de key van het project nodig zodat het ook voor deze persoon opgeslagen kan worden met zijn wachtwoord.

Nee, als het systeem de key niet heeft dan kan het systeem het niet voor je delen, zo simpel is het. Maar eh, waarom niet à la dropbox, gewoon met wachtwoord inloggen, en op basis daarvan toegang tot bepaalde bestanden geven? Dan kun je gemakkelijk maken dat je bestanden kan delen.

En worden de bestanden dus niet encrypted opgeslagen, nja wel, maar is er een master-key dus mochten autoriteiten op de stoep staan zul je die sleutel ook moeten overhandigen.

Als het gevoelige data is zul je dan natuurlijk wel moeten zorgen dat men niet zonder toestemming op het systeem kan, maar een autorisatie-probleem moet je toch al oplossen.

Er is uiteraard authorisatie, maar ik probeer het zo op te zetten dat ik als eigenaar van het systeem ook niet weet wat er staat en er dus niet in kan kijken.

Nu krijg je ook leuke effecten als "wachtwoord weg, data weg". Niet echt fool-proof, afhankelijk van het type gebruiker.

Hier heb je een punt, dit gaat inderdaad niet werken, je zou een wachtwoord vergeten optie kunnen maken, maar als je je wachtwoord bent vergeten kan je geen nieuw wachtwoord opvragen, nja dat kan je wel doen, maar je kan dan daarna alsnog niet meer bij je data.

Je zou een key naar de gebruiker kunnen sturen met 'schrijf deze op' hiermee zou je als je je wachtwoord kwijt bent je data kunnen terughalen, maar dat is ook niet echt gebruikersvriendelijk.

Als je de keys versleuteld via asymetrische encryptie, kan je de versleutel-kant van iedere gebruiker wel gewoon op je server bewaren. Dan kan je achteraf alsnog een bekend geworden key versleutelen op naam van alle duplicaateigenaren, zonder dat je hun wachtwoord hoeft te weten.
In dat geval kan je bij het uploaden van het duplicaat de oude file verwijderen en de nieuwe ontsleutelkey bij zowel de oude als nieuwe gebruiker opslaan.

Die client kan ook een web-service zijn, daar kan je dan moeilijk de helft van de key bij de gebruiker opslaan.

Conclusie is dan toch ben ik bang: "It cannot be done."

Er blijft een 'master' key nodig om de bestanden te kunnen decrypten anders zit je of met het wachtwoord probleem aangewezen door bwerg of met de onmogelijkheid om data duplicatie tegen te gaan.

[Patriot]

Deduplicatie is toch nagenoeg onmogelijk? Op de server staat bestand A, die is geüpload door gebruiker A. Vervolgens upload gebruiker B een bestand B dat unencrypted bit voor bit hetzelfde is als bestand A. Echter, bestand A is encrypted met een key die je niet kent en hetzelfde geldt voor bestand B.

Sowieso zou ik gebruik maken van assymetrische encryptie, en dan is het eigenlijk zo dat je op de server *nooit* toegang hoeft te hebben tot ofwel de gegevens zonder encryptie ofwel de mogelijkheid om de gegevens überhaupt te decrypten. Dan zijn dus zelfs gegevens van ingelogde gebruikers veilig. Ik vind je huidige opzet (de server kent keys) onverenigbaar met het doel "Ik / medewerkers moeten geen toegang hebben tot de un-encrypte data". In een groot deel van de gevallen is dat gewoon niet zo.

Daarnaast doet deze uitspraak:

Die client kan ook een web-service zijn, daar kan je dan moeilijk de helft van de key bij de gebruiker opslaan.

Het systeem in de huidige opzet lijkt me niet iets dat je middels een simpele webinterface wilt ontsluiten. Eigenlijk zie ik het dan niet meer veilig worden.

[ZpAz]

Via dropbox kan je ook via de webinterface bij de data. Deze heeft dus hetzelfde probleem. De reden dat daar dus een master key is. Immers kan je een wachtwoord reset opvragen en dit zou niet mogelijk zijn als je zelf de encryptie key aanlevert.

Hetzelfde geld voor bijvoorbeeld een email service alla gmail.

Vind je dat dan ook niet veilig?

De enige mogelijkheid is dat je je wachtwoord niet kan resetten wil je als eigenaar van de service niet bij de content kunnen komen. Maar op het moment dat de klant zijn wachtwoord dan kwijt is is hij al zijn data ook kwijt.

Ik dacht een oplossing te hebben voor dit probleem, maar de wachtwoord reset feature waar ik geen rekening mee had gehouden, uitgewezen in de eerste reactie wijdt meteen al uit dat dit niet kan.

Helaas.

[bwerg]

Hoe weet je dat dropbox überhaupt aan encryptie van zijn bestanden doet? Naar mijn weten wordt alleen de toegang tot bestanden gelimiteerd, maar is de opslag onversleuteld:

Dropbox employees are prohibited from viewing the content of files you store in your account. Employees may access file metadata (e.g., file names and locations) when they have a legitimate reason, like providing technical support. Like most online services, we have a small number of employees who must be able to access user data for the reasons stated in our privacy policy (e.g., when legally required to do so).

Een versleuteling binnen een systeem, en dan daarvoor de key hebben binnen datzelfde systeem, heeft natuurlijk vrij weinig toegevoegde waarde en lost jouw probleem ook totaal niet op.

Conclusie is dus dat het niet mogelijk is. Eventueel zou je natuurlijk wel een infrastructuur kunnen bedenken waarbij het uitwisselen van sleutels uiteindelijk nog steeds via de eindgebruikers verloopt (en het systeem deze dus nooit te weten komt), en het systeem die uitwisseling vergemakkelijkt. Dan geldt nog steeds dat je een probleem hebt bij het vergeten van je wachtwoord maar dat is inherent aan een systeem waarbij alleen de gebruiker een bestand kan ontsleutelen.

[ Voor 7% gewijzigd door bwerg op 03-12-2012 00:20 ]

[Patriot]

ZpAz schreef op zondag 02 december 2012 @ 23:56:
Via dropbox kan je ook via de webinterface bij de data. Deze heeft dus hetzelfde probleem. De reden dat daar dus een master key is. Immers kan je een wachtwoord reset opvragen en dit zou niet mogelijk zijn als je zelf de encryptie key aanlevert.

Hetzelfde geld voor bijvoorbeeld een email service alla gmail.

Vind je dat dan ook niet veilig?

Het vertrouwen in de veiligheid plaats ik in ieder geval niet vanwege de encryptie. Als ze inderdaad systemen gebruiken waarbij de keys bekend zijn op het systeem is het wat encryptie betreft inderdaad een onveilig systeem.

De enige mogelijkheid is dat je je wachtwoord niet kan resetten wil je als eigenaar van de service niet bij de content kunnen komen. Maar op het moment dat de klant zijn wachtwoord dan kwijt is is hij al zijn data ook kwijt.

Ja, natuurlijk is dat zo. Dat is ook niet meer dan logisch. Vergelijk het met een kluisje dat je verhuurt. Als er maar 1 sleutel is en die sleutel geef je mee aan je huurder, dan zul je die huurder nooit toegang tot het kluisje kunnen verlenen als hij die sleutel kwijtraakt.

[johnkeates]

Als je een systeem wil maken waarbij d.m.v. encryptie iets gecodeerd is, maar je wil dat alleen de gebruiker die het bestand upload de sleutel heeft, dan kan je alles wat je verder wil doen wel vergeten Dan krijg je een soort van veredelde fileserver. Probleem is namelijk dat als je het echt veilig wil maken, je de decryptie op de PC van de eindgebruiker laat doen, zodat je zelf nooit de sleutel krijgt.

[H!GHGuY]

Ik heb een tijd terug over hetzelfde idee zitten tobben, maar dan met een totaal andere toepassing:
social media.

Je maakt een profiel aan. Hiermee is een public/private key pair verbonden. Beide keys sla je op bij de gebruiker. De gebruiker publiceert profiel informatie, dewelke is geencrypteerd met zijn private key.
Om andere personen het profiel te laten zien stuur je hen je public key. Zij kunnen vanaf dan alles volgen.

Je loopt hier echter tegen enkele van dezelfde problemen aan:
- een public key kun je niet afnemen (aka de-'friend'en use-case). Wel kun je de public key vervangen van iedereen die wel nog toegang moet krijgen. Dit kun je doen zonder dat die gebruiker het merkt (nieuwe public key pushen)
- Je kan verschillende niveau's van privacy instellen door de data met meerdere keys te encrypten. Qua storage is dit echter teveel. Wat je dan zou kunnen doen is de ruwe data symmetric encrypten en de key daarvan met je private keys encrypten.

Dit laatste punt kun je zelfs nog doortrekken als je elke user die je data mag zien een eigen key geeft. Dan kun je een key revoken door de symmetric key, encrypted met de key voor die user, te verwijderen.

Als je het nog verder doortrekt dan:
- publiceer je data met je symmetric key en voeg je per user die je data mag zien een tag toe waarin de symmetric key geencrypteerd is met de public key van die user.
- iemand toegang geven betekent dus dat die persoon bij accepteren, jou zijn public key zendt.
- toegang verwijderen betekent tags van je data halen.

Dit kan allemaal weggemoffeld worden zodat Jan Modaal er niets van ondervindt, zijn privacy niet te grabbel is gegooid en hij toch alles kan doen wat die andere sociale media kunnen.

[Gerco]

@HighGuy:
Met public key crypto is het niet de bedoeling om je public key geheim te houden. Om data te verbergen voor iemand anders ga je dan ook niet je public key achter houden. Die key kan hij wel op een andere manier verkrijgen (van iemand anders die de data wel kan zien, bijvoorbeeld).

Wat je kan doen is het volgende:
1. Bij het aanmaken van een account op de site maak je voor de gebruiker een keypair aan met een secret key (SK) en een public key (PK). SK blijft eigendom van de gebruiker en PK zet je in een database tabel voor later gebruik.

2. Je encrypt de profiel gegevens met een symmetric key (Ks).

3. Je encrypt Ks met de public key van iedereen die je toegang wilt verlenen tot een profiel. EKvriend = E(PKvriend, Ks). Deze encrypted keys sla je ook gewoon publiek op, het is niet nodig om die via een geheim mechanisme uit te wisselen aangezien alleen de persoon met de bijhorende SKvriend de originele Ks weer kan decrypten en het profiel kan inzien.

Op die manier kun je iemand bevrienden en ontvrienden zonder handmatig keys te gaan uitwisselen of nieuwe keys te gaan pushen. Wanneer je iemand ontvriend verwijder je gewoon EKvriend en wanneer je een nieuwe vriend toevoegt maak je een nieuwe EKvriend aan voor die vriend.

On-topic:
Hoe dit alles toe te passen is op een dropbox-achtige site met deduplicatie en onmogelijkheid om gegevens te decrypten wanneer de wet daarom vraagt is me een raadsel.

Voor zover ik het begrijp is het best mogelijk om encrypted gegevens de deduppen, maar alleen wanneer de site zelf de gegevens kan decrypten. Als decrypten niet kan kun je namelijk alleen duplicates detecteren (via client-side hashing), maar je kan er vervolgens niets nuttig mee doen. Je hebt de encryptie key van de gegevens niet dus kun je die key ook niet opnieuw encrypten voor de nieuwe gebruiker van hetzelfde datablok.

[Patriot]

H!GHGuY schreef op maandag 03 december 2012 @ 12:47:
Je maakt een profiel aan. Hiermee is een public/private key pair verbonden. Beide keys sla je op bij de gebruiker. De gebruiker publiceert profiel informatie, dewelke is geencrypteerd met zijn private key.
Om andere personen het profiel te laten zien stuur je hen je public key. Zij kunnen vanaf dan alles volgen.

De termen public key en private key worden niet gebruikt voor de keys waarvan jij kiest om ze publiekelijk bekend te maken danwel privé te houden. De public key is de key waarmee je kunt encrypten. De private key is de key waarmee je kunt decrypten. Als jouw profiel encrypted is en je wilt anderen die laten decrypten dan moet je dus je private key doorsturen. Daaruit valt de public key gewoon te genereren (andersom niet), dus effectief is het sharen van de private key hetzelfde als het sharen van de key in het geval van symmetrische encryptie.

[Janoz]

Sorry Patriot, maar dat is onzin.

Asynchrone encryptie is niks meer en niks minder dan een encryptie methode waarbij je voor encryptie een andere sleutel nodig hebt dan decryptie. Binnen dit sleutelpaar zijn de sleutels gewoon gelijkwaardig. Je kunt de ene niet afleiden van de andere. Je kunt ze wel omdraaien. Kortom: Encrypten met sleutel A dan decrypten met sleutel B. Encrypten met sleutel B dan decrypten met sleutel A.

Vervolgens is hier omheen een soort workflow bedacht. Als je namelijk een stukje content kunt decrypten met sleutel B, dan is het zeer waarschijnlijk dat het geencrypt is met sleutel A. Als je daarbij de garantie hebt dat entiteit X de enige is die sleutel A kent dan kun je met aan zekerheid grenzende waarschijnlijkheid aannemen dat de data die je gekregen hebt wel van entiteit X moet komen en dat vanaf het versleutelen door entiteit X er helemaal niemand is geweest die de inhoud aan heeft kunnen passen.

Het verschil tussen een private en public key is dus helemaal niet technisch, maar puur procedureel.

---edit--

Hmm... blijkbaar verkondig ik ook onzin . Na toch wat doorlezen blijkt het eigenlijk nogal implementatie afhankelijk te zien.

[ Voor 6% gewijzigd door Janoz op 03-12-2012 16:56 ]

[Patriot]

Janoz schreef op maandag 03 december 2012 @ 16:52:
Sorry Patriot, maar dat is onzin.

Ik was al bang dat ik een disclaimer toe had moeten voegen. Het is inderdaad zo dat niet bij iedere pkc algo de public key uit de private key te halen valt. Wel bij bijv. RSA, en zo zijn er nog wel meer waarbij het genereren van de public key een eitje is.

Mijn verhaal is net zo min onzin als jouw verhaal, het is gewoon niet altijd waar.

EDIT:
En gezien je eigen edit was je zelf ook al tot die conclusie gekomen

[ Voor 8% gewijzigd door Patriot op 03-12-2012 17:01 ]

[leuk_he]

eeeh... voordat je iets bouwt, het bestaat vast al.

https://spideroak.com/ b.v. is een soort dropbox waar de key alleen op de client wordt opgeslagen.

enne, deduplicatie is daar nog wel op de client mogelijk, dat als je meerdere versies van eenzelfde groot bestand wordt opgeslagen, daar alleen de verschillen in de cloud worden gezet.

maar voordat je gaat bouwen, vaak bestaat het al,...

[ZpAz]

Spideroak past inderdaad zoiets toe, maar heeft dus niet de sharing mogelijkheden e.d. Die was ik al tegengekomen. Spideroak is gewoon een 'backup-service' waar jij de key in handen hebt.

[Gomez12]

Wat wil je deduppen? Als het namelijk om giga-hoeveelheden data gaat dan zijn er wel wat trucjes te verzinnen als data encrypten, de ge-encrypte data opdelen in stukjes en dan per stukje gaan deduppen.

Maar dan maak je het wel erg complex en bij meerdere servers moet je ook rekening gaan houden waar de stukjes staan en je hebt een giga-hoeveelheid data nodig.

Alternatief idee waar ik zelf wel eens aan gedacht heb is de folder in 2'en te delen : Completely private, semi-private. Waarbij completely private echt met de key van de client wordt gedaan en semi-private met een server-key.
Idee hiervan was dat de echt private bestanden toch zo goed als niet te deduppen zullen zijn, het deduppen wil je vooral over de foto's / muziek / filmpjes / iso's van de gebruiker doen en die zijn over het algemeen ook niet direct completely private.

Het delen / deduppen kan dan gewoon over de semi-private data gaan.

Maar vergeet 1 belangrijk ding niet bij "cloud" dingen, alles is daar te kraken. Het kost enkel wat tijd, en de gebruiker heeft geen invloed of een delete een echte delete is of een soft-delete.

Als serverbeheerders gewoon elke dag een backup trekken van de encrypted data dan kan het 1000 jaar duren voor de encryptie gebroken wordt, maar het meest private bestandje kan dan gelezen worden (na 1000 jaar) en de gebruiker kan daar niets aan doen.

[The Eagle]

Even je lijstje met eisen nog eens:

1. Dit systeem heeft de volgende eisen:
2. Encrypted opslaan bestanden
3. Duplicatie in data voorkomen (minder opslag ruimte, sneller uploaden van gelijke bestanden)
4. Mogelijkheid om de data te delen met andere gebruikers van de service
5. Ik / medewerkers moeten geen toegang hebben tot de un-encrypte data

Oracle DB's kunnen data encrypted opslaan, met grote bestanden omgaan, uniciteit in bestanden hebben, controle op bestaande data doen irt duplicates, data delen met andere gebruikers...en het afgrendelen van toegang is ook een fluitje van een cent, zeker als je er een front-end tegenaan hangt die tegen een encrypte backend praat. Alleen het kost een paar centen

Dus vraag 1: wat is je budget?
En vraag 2: wat wil je hiermee bereiken

[johnkeates]

The Eagle schreef op maandag 03 december 2012 @ 21:57:
Even je lijstje met eisen nog eens:

1. Dit systeem heeft de volgende eisen:
2. Encrypted opslaan bestanden
3. Duplicatie in data voorkomen (minder opslag ruimte, sneller uploaden van gelijke bestanden)
4. Mogelijkheid om de data te delen met andere gebruikers van de service
5. Ik / medewerkers moeten geen toegang hebben tot de un-encrypte data

Oracle DB's kunnen data encrypted opslaan, met grote bestanden omgaan, uniciteit in bestanden hebben, controle op bestaande data doen irt duplicates, data delen met andere gebruikers...en het afgrendelen van toegang is ook een fluitje van een cent, zeker als je er een front-end tegenaan hangt die tegen een encrypte backend praat. Alleen het kost een paar centen

Dus vraag 1: wat is je budget?
En vraag 2: wat wil je hiermee bereiken

Nee, een Oracle DB voldoet niet, om dat het de data zelf codeert en decodeert, en slecht met credentials een authenticatie van een gebruiker doorvoert. Daarnaast heb ik mijn twijfels over de 'beveiliging' van een systeem dat in een land ontwikkeld wordt dat ook de PATRIOT Act heeft.

[Gomez12]

@The Eagle, db-toegang dichtzetten lijkt me niet genoeg om te voldoen aan voorwaarde 5. Dan kunnen nog steeds de dba's bij de unencrypted data.

Jouw voorstel gebruikt maar 1 key, terwijl als ik het goed begrijp de TS juist 1 key per gebruiker wil hebben.

En 1 key solution is vrij simpel op te zetten (nouja simpel, het is goed te doen zal ik maar zeggen) en kan op jouw manier met elke db die encrypted dbases ondersteunt.

Btw @TS wellicht moet je trouwens eens gaan nadenken of je echt geen eigen mogelijke toegang tot de bestanden wilt hebben, een gmail / hotmail.com /dropbox etc werken ook allemaal met shared keys juist om te kunnen deduppen. Alleen is dat contract-technisch afgedicht.

[The Eagle]

Oracle levert het niet standaard mee, maar je kunt Oracle Advanced seccurity inzetten en dan kunnen de DBA's weliswaar de data in de tabellen zien, maar dan staat er toch echt iets als "laijsdhgoiuahlkvbadklsjryhglwijkhrglkabcklabnlak"

Sowieso, hoe je het ook wend of keert: er zal vrijwel altijd iemand zijn die op een hoog niveau toegang heeft. Als je alles af wilt grendelen voro iedereen kom je op een gegeven moment bij een systeem uit dat voor niemand meer werkbaar is, omdat ze voor iedere poep of scheet toegang aan moeten vragen.

Ik heb vorig jaar bij een klant gezeten die 100% compliant wilde zijn met zijn systeem. Dat was zo diep doorgevoerd dat ik pas na een maand of anderhalf kon doen wat ik moest doen, en dat het oplossen van indicenten als gevolg van simpele rechtenkwesties geen 3 dagen maar 3 weken duurde. Je kunt je voorstellen dat de business dat systeem vrij snel heel erg zat was - en ik ook

Kortom: bezint eer ge begint. Werken in een kluis is veilig want niemand kan je aanraken, maar er komt van buiten ook geen werk bij omdat niemand bij je kan komen

[leuk_he]

ZpAz schreef op maandag 03 december 2012 @ 17:43:
Spideroak past inderdaad zoiets toe, maar heeft dus niet de sharing mogelijkheden e.d.

Je kunt wel directories sharen in dropbox achtige stijl. Maar dan share je dus ook de ook meteen de decrypty key voor die share.


Zelf ook wel eens lopen zoeken hoe dit simpel te maken...
Hier is b.v. eenlijstje met open
http://www.webresourcesde...e-storage-sharing-system/

Ik zie in de oracle "oplossing" geen oplossing, want je grootste probleem is toch het keymanagement, en dat mag je dus zelf nog uitvogelen. Ja, er is wel een key-safe, maar wat je daarin opslaat is belangrijker dan hoe. (En daar zijn ze bij drop box wel een paar keer heel erg nat gegaan)

[H!GHGuY]

Gerco schreef op maandag 03 december 2012 @ 13:19:
Wat je kan doen is het volgende:
1. Bij het aanmaken van een account op de site maak je voor de gebruiker een keypair aan met een secret key (SK) en een public key (PK). SK blijft eigendom van de gebruiker en PK zet je in een database tabel voor later gebruik.

2. Je encrypt de profiel gegevens met een symmetric key (Ks).

3. Je encrypt Ks met de public key van iedereen die je toegang wilt verlenen tot een profiel. EKvriend = E(PKvriend, Ks). Deze encrypted keys sla je ook gewoon publiek op, het is niet nodig om die via een geheim mechanisme uit te wisselen aangezien alleen de persoon met de bijhorende SKvriend de originele Ks weer kan decrypten en het profiel kan inzien.

Op die manier kun je iemand bevrienden en ontvrienden zonder handmatig keys te gaan uitwisselen of nieuwe keys te gaan pushen. Wanneer je iemand ontvriend verwijder je gewoon EKvriend en wanneer je een nieuwe vriend toevoegt maak je een nieuwe EKvriend aan voor die vriend.

Dat is exact wat ik op het einde beschrijf, toch? Maar dan misschien iets duidelijker geformuleerd.