Public-key cryptography en database.

[MasterTweaker]

Ik ben een online bibliotheek aan het ontwerpen waarbij ik Public-key cryptography wil toepassen om te voorkomen dat gebruikers uitgeleende boeken kunnen kopiëren en verspreiden.

Je hebt dan dus een public key en een private key:

http://publiespe.espe.edu...dadweb/seguridadweb-2.gif

Maar nu vraag ik mij af hoe deze sleutels in de database opgeslagen moeten worden. In de afbeelding hieronder is een stukje te zien van het logische databaseontwerp van de online bibliotheek:



Zoals te zien heb ik nu een tabel genaamd: "Keys" met daarin drie kolommen:
- Keynr
- Encryptionkey ( public key)
- Decryptionkey ( private key)

Als een gebruiker een boek leent dan wordt er een publieke sleutel en private sleutel gegenereerd.

Nu heb ik hierover de volgende vragen:
- Heb je dan per boek een public key nodig? Of is er 1 public key per boek?
- Is dit een veilige database opzet?
- Dienen de keys zelf ook weer geëncrypteerd te worden?

[ Voor 5% gewijzigd door MasterTweaker op 28-05-2012 15:05 ]

[Nick_S]

Ik denk dat de belangrijkste vraag is, hoe je gaat voorkomen dat mensen de public key gewoon samen met het boek gaan verspreiden.

Dan zou ik nog de public key per lid maken ipv per boek, zodat je keys kan herleiden naar mensen in geval van misbruik. En misschien ook een watermerk in het boek zetten met de gebruikersnaam, zodat uitgelekte boeken te herleiden zijn en mensen ook zien dat het een persoonlijk object is en hierdoor verspreiding tegen te gaan.

[Rigi]

Het kan aan mij liggen, maar ik snap je opzet niet zo goed. Waarom zou je de private key naast de public key opslaan? (en in de meeste gevallen, waarom zou je die private key uberhaupt willen opslaan?) Ik zou de gebruiker (client software?) een public key laten leveren en dan alle boeken die hij uitleent eerst encoderen met die key voor je ze naar hem opstuurt. Je moet denk ik sowieso goed nadenken over hoe je gaat voorkomen dat de gebruiker een boek decodeert en dan verspreid.

[Marcks]

Boeken versleuteld uitwisselen kan voorkomen dat een aanvaller de communicatie onderschept en kan uitlezen, maar wil de klant het boek kunnen lezen, dan moet hij de informatie kunnen decoderen. Als de ontvanger en de aanvaller dezelfde persoon zijn, kan de aanvaller dat dus ook. Cryptografie doet niets om te voorkomen dat gebruikers uitgeleende boeken gekopieerd en verspreid worden.

Sterker nog, de enige technische maatregel die dat wel kan bewerkstelligen, is de boeken niet uitlenen.

[MasterTweaker]

Rigi schreef op maandag 28 mei 2012 @ 15:13:
Het kan aan mij liggen, maar ik snap je opzet niet zo goed. Waarom zou je de private key naast de public key opslaan? (en in de meeste gevallen, waarom zou je die private key uberhaupt willen opslaan?) Ik zou de gebruiker (client software?) een public key laten leveren en dan alle boeken die hij uitleent eerst encoderen met die key voor je ze naar hem opstuurt. Je moet denk ik sowieso goed nadenken over hoe je gaat voorkomen dat de gebruiker een boek decodeert en dan verspreid.

Oke als ik het goed begrijp zou jij het dus als volgt doen:
- De gebruiker leent een boek.
- Er wordt een unieke sleutel gegenereerd op basis van de gebruikers id, het boek nummer, en het uitleningsnummer (lendingnr) en een hardware id.
- Het boek wordt geyncrypteerd met deze sleutel en vervolgens opgestuurd te samen met de sleutel
- Vervolgens kan het boek weer worden gedecrypteerd met deze sleutel.

Nu kan het boek niet gekopieerd worden omdat het boek alleen leesbaar is op de unieke pc van de gebruiker.

[Freeaqingme]

Volgens mij ga je ook nog een IV willen opslaan. Die wil je wel iedere keer anders hebben.

[azerty]

MasterTweaker schreef op maandag 28 mei 2012 @ 16:24:
[...]

Oke als ik het goed begrijp zou jij het dus als volgt doen:
- De gebruiker leent een boek.
- Er wordt een unieke sleutel gegenereerd op basis van de gebruikers id, het boek nummer, en het uitleningsnummer (lendingnr) en een hardware id.
- Het boek wordt geyncrypteerd met deze sleutel en vervolgens opgestuurd te samen met de sleutel
- Vervolgens kan het boek weer worden gedecrypteerd met deze sleutel.

Nu kan het boek niet gekopieerd worden omdat het boek alleen leesbaar is op de unieke pc van de gebruiker.

Als je het boek op een andere pc decrypteerd met een doorgespeelde sleutel, waarom zou dit dan niet werken? Tenzij je het ophalen van de sleutel in je eigen programma automatisch maakt, maar met een beetje decompilen en reverse-engineeren maak je je eigen app die een versleuteld bestand en een public key accepteert... En eenmaal de gebruiker het (al dan niet met jouw app) gedecrypteerd heeft, hoe ga je dan de verspreiding tegen?

Ik zou met een watermark werken, en de in de sleutel dan op zen minst een gebruikers-id verwerken, zodat je bij verspreiding de bron kunt achterhalen (of toch kunt proberen), zoals hierboven aangegeven.

[MasterTweaker]

wsitedesign schreef op maandag 28 mei 2012 @ 16:48:
[...]


Als je het boek op een andere pc decrypteerd met een doorgespeelde sleutel, waarom zou dit dan niet werken? Tenzij je het ophalen van de sleutel in je eigen programma automatisch maakt, maar met een beetje decompilen en reverse-engineeren maak je je eigen app die een versleuteld bestand en een public key accepteert... En eenmaal de gebruiker het (al dan niet met jouw app) gedecrypteerd heeft, hoe ga je dan de verspreiding tegen?

Ik zou met een watermark werken, en de in de sleutel dan op zen minst een gebruikers-id verwerken, zodat je bij verspreiding de bron kunt achterhalen (of toch kunt proberen), zoals hierboven aangegeven.

Omdat het software component waarmee men het ebook of pdf bestand kan lezen onderdeel is van de software. En dus wordt er bij het decrypteren door de software gecontroleerd of de "hardware id" nog overeenkomt met het hardware id waarmee het boek gedownload is. En daarnaast dient de gebruiker ook met zijn eigen account in te loggen want daar is de sleutel ook aangekoppeld.

[djluc]

Je oplossing kan prima werken zolang je maar weet dat je zodra je het boek als daadwerkelijke tekst op de client geeft het weg is. Dan is je beveiliging niet meer aanwezig. Daar kan je simpelweg niets aan doen. Dit komt omdat je het leesbaar moet maken voor de client.

Het zou handig zijn als je eerst je doel duidelijk maakt:

waarbij ik Public-key cryptography wil toepassen om te voorkomen dat gebruikers uitgeleende boeken kunnen kopiëren en verspreiden

Als dit je doel is zit hier een bepaalde grens aan. Je stelt het boek namelijk beschikbaar dus het kan nou eenmaal verspreid worden. Al maak je maar een foto van je scherm en scan je die weer in met OCR o.i.d. dus het kan altijd.

Wat je geeft aan de gebruiker kan verspreid worden.

Is het voldoende om het zo lastig mogelijk te maken? Volstaat dat of moet het echt beveiliging op niveau van een bank zijn? Op welk niveau is verlies acceptabel? Een hacker die de tekst uit z'n geheugen plukt of een eigen fake client maakt wil je voorkomen?

MasterTweaker schreef op maandag 28 mei 2012 @ 17:50:
[...]

Omdat het software component waarmee men het ebook of pdf bestand kan lezen onderdeel is van de software. En dus wordt er bij het decrypteren door de software gecontroleerd of de "hardware id" nog overeenkomt met het hardware id waarmee het boek gedownload is. En daarnaast dient de gebruiker ook met zijn eigen account in te loggen want daar is de sleutel ook aangekoppeld.

Het helpt niet echt omdat je simpelweg een client kan faken. Dus eerst je gewenste niveau bepalen.

[ Voor 29% gewijzigd door djluc op 29-05-2012 09:28 ]

[leuk_he]

Key per boek of key per uitlening? Tja, dat ligt er aan

als je b.v.

http://www.adobe.com/products/digitaleditions/faq/

adobe drm bekijkt, dan is een boek geencrypt met een userid en een key per boek. Zodat de gebruiker geen extra kopieen kan maken. Dat is dues het doel van commerciele DRM, geen extra kopieën op een makkelijke manier. Dan moet je dus een database van clients(hardwareid) bijhouden. die hardware zou je dus wellicht aan de klant moeten hangen (1 of meer hardware id's), en niet aan een uitlening.

Wellicht is jouw doel anders. b.v. dat niemand het boek kan veranderen. een key voor alle boeken al voldoende. ( nou ja, en een versie nummer, als een key gelekt is moet je terug kunnen vallen op een 2e key ofzo)

Maar om deze vragen goed te beantwoorden moet je dus nu al kijken welke software je gaat gebruiken (vergeet niet heel goed te kijken naar de licentiekosten, vooral als dat niet erbij staat) . Want elke software zal zijn eigen nukken hebben en mogelijkheden. Zelf DRM software schrijven kan uiteraard ook, maar onderschat dat niet.

[MueR]

Ik tik dit topic even naar Software Engineering & Architecture, daar past het wat beter

[TRON]

Is het niet handiger voor je om de boeken op elke pagina een watermerk te geven met de gegevens van de persoon die het boek leent? Dat heeft een afschrikkend effect en mocht iemand het verspreiden, dan kan je dat enigszins traceren.

Zorg er tevens voor dat de tekst geen tekst is, maar een plaatje, dan is het kopiëren ook iets lastiger geworden.