Versleutelen van files en koppelen aan gebruiker

[NickThissen]

Ik werk aan een applicatie waarmee gebruikers hun eigen content kunnen maken. Voor het gemak, laten we zeggen dat de gebruikers een soort powerpoint presentaties maken. Deze presentaties zijn misschien ook voor andere mensen interessant, en ik ben bezig om een soort online "winkel" te maken waar men hun creaties kunnen delen. De bedoeling is dat de gebruikers zelf kunnen kiezen of ze hun presentatie gratis aanbieden of er geld voor vragen. Ik heb een server online waar de presentaties naar geupload worden, en waarvan ze dan door andere gebruikers weer gedownload worden.

Ik probeer nu een manier te verzinnen waarop ik ervoor kan zorgen dat mensen de presentaties van anderen niet zomaar kunnen delen (oftewel, Pietje koopt een presentatie van Jantje en stuurt deze daarna naar 15 mensen door en deelt de kosten). Ik wil een presentatie dus kunnen koppelen aan de gebruiker die deze gekocht heeft, zodat hij niet door anderen te gebruiken is.

Een belangrijk punt: het opslaan en laden van een presentatie in de client moet ook kunnen werken zonder verbinding met de server. Mocht de server een keer down zijn of de gebruiker zonder internet zitten dan wil ik niet dat de applicatie onbruikbaar is.


Ik ben een klein beetje bekend met encryptie, maar waarschijnlijk niet genoeg om dit op een slimme manier op te lossen. Ik heb het volgende bedacht:

- Ik geef elke gebruiker een eigen unieke "key" en sla deze op in de database op de server.
- De gebruiker moet inloggen op de client applicatie om presentaties te kunnen uploaden. Tijdens inloggen kan de client de key van de gebruiker ophalen.
- Bij het uploaden wordt de presentatie file versleuteld met deze key via symmetrische encryptie. De versleutelde versie wordt opgeslagen en naar de server geupload.
- Bij het inladen van een presentatie file wordt de file ontsleuteld met de key van de ingelogde gebruiker. Alleen als de key overeenkomt (oftewel, als het dezelfde gebruiker is) zal de presentatie dus kunnen laden.
- Als een andere gebruiker een presentatie wil downloaden, dan wordt de file op de server eerst ontsleuteld met de key van de eigenaar (deze is op de server natuurlijk bekend). Daarna wordt hij weer versleuteld met de key van de koper. Op deze manier kan alleen de koper de file laden.


(Ik heb ook beschikking over asymmetrische encryptie; de server heeft een private key en de client kent een public key welke we al voor andere doeleinden gebruiken. De files bevatten echter afbeeldingen etc en kunnen vaak wel 50+ MB groot zijn. Volgens mij is asymmetrische encryptie dus geen optie, in ieder geval niet direct.)


Volgens mij moet dit werken; de file kan alleen geopend worden als hij opgeslagen (of gedownload) is door de gebruiker waarmee hij encrypted is. Zowel opslaan als inladen van een presentatie werkt ook offline als de key lokaal bekend is.

Maar ik zie een groot probleem... De unieke key van de gebruiker moet op de client opgeslagen worden. Een slimme gebruiker kan doorhebben hoe de boel werkt en gewoon zijn key opzoeken en deze delen met zijn vrienden. Zijn vrienden kunnen hun key dan veranderen en alsnog presentaties openen die niet van hunzelf zijn.

Hoe voorkom ik dit? Dit lijkt me een probleem dat al opgelost moet zijn... Maar ik kan geen manier verzinnen om dit te laten werken. Het enige wat ik kon bedenken is om de unieke key op een of andere manier het ID van een user te laten bevatten. Stom voorbeeld: gewoon een random string met het ID er achter geplakt. Bij het ontsleutelen kan dan gewoon gekeken worden of het ID in de key overeenkomt met het ID van de huidige gebruiker. Zo niet dan klopt er iets niet. Maar hier hetzelfde probleem: ook het ID moet gewoon lokaal in een database ofzo staan, en is dus in principe ook aan te passen...


Kan ik iets bereiken met de asymmetrische encryptie? Ik kan het niet bedenken...


Ben ik gewoon te moeilijk aan het doen? Ik kan me niet voorstellen dat ik gebruikers krijg die slim genoeg zijn om hun key te zoeken en aan te passen, maar het is in principe natuurlijk mogelijk en als er een goeie manier is om dit te voorkomen dan pas ik dat graag toe.

[DJMaze]

http://php.net/openssl_seal voor verdere uitleg zoek even in het forum hier, ik heb al eerder antwoord gegeven op een andere vraag met dit antwoord.
Het is nog niet de oplossing, maar het helpt je op weg.
Zodra je het begrijpt los je het vast op in 10 minuten (dat deed ik net ook voor je, maar verwacht eigen inzet).

[ Voor 36% gewijzigd door DJMaze op 03-03-2017 21:00 ]

[RobIII]

Wat je zoekt is gewoon DRM.

[NickThissen]

DJMaze schreef op vrijdag 3 maart 2017 @ 20:52:
http://php.net/openssl_seal voor verdere uitleg zoek even in het forum hier, ik heb al eerder antwoord gegeven op een andere vraag met dit antwoord.
Het is nog niet de oplossing, maar het helpt je op weg.
Zodra je het begrijpt los je het vast op in 10 minuten (dat deed ik net ook voor je, maar verwacht eigen inzet).

Je bedoelt deze post? DJMaze in "Welke versleuteling database voor persoonsgegevens?"

Ik ga er nog eens een keer of 10 overheen lezen.... Maar ik begrijp het hele principe er achter nog niet echt.

Ik zoek (nog) niet echt naar een implementatie (ik gebruik overigens .NET Core, niet PHP), ik wil eerst begrijpen hoe het in theorie zou moeten werken.

[NickThissen]

RobIII schreef op vrijdag 3 maart 2017 @ 22:10:
Wat je zoekt is gewoon DRM.

Hmm, waarschijnlijk wel ja...

Alles wat ik kan vinden over DRM implementatie lijkt eigenlijk niet eens zo heel anders als mijn eerste idee, en heeft ook het probleem dat de gebruiker toegang moet hebben tot een key om zijn data te encrypten, terwijl je hem die toegang eigenlijk niet wil geven.

Is mijn idee om per user een key op te slaan (ook lokaal) dan gewoon een extreem simpele versie hier van? Als het nodig is kan ik wel mijn best doen om deze key ergens te gaan verstoppen maar dit soort security by obscurity is natuurlijk altijd vrij eenvoudig te kraken.

[Gomez12]

Simplistisch gezien kan wat jij wil simpelweg niet, jij wilt even de heilige graal van de contentindustrie waar ze al tig jaar zoeken zelf gaan bouwen.

Of je hebt een online check waartegen je alles kan valideren of het is gewoon het zo goed mogelijk verbergen van een stukje lokale code genaamd een key.

Alleen het is ook gewoon vanaf de andere kant een risk-reward berekening die je mee kan calculeren. Sta bijv maar 1 user key tegelijk toe, dan kan pietje wel 1 presentatie met 15 man delen, maar diezelfde 15 man kan dan niets anders doen dan deze presentatie. Oftewel zolang je meer dan 1 goede presentatie hebt is het niet eens zo'n groot probleem.
Verwerk ook in je key een soort van aflopende datum (desnoods meerdere varianten) zodat je app 1x per week probeert de key te vernieuwen. Lukt dit voor 4 weken niet dan wordt de presentatie gedisabled totdat hij wel weer server geverifieerd is etc.

[NickThissen]

Dat is eigenlijk wel logisch ja. Ik ga er nog eens over nadenken... misschien is het wel genoeg om de key gewoon in een lokale db te gooien, ik verwacht uberhaupt niet dat iemand moeite gaat doen om dit systeem te omzeilen dus ik wil er ook niet te veel moeite in stoppen.