Key management

[Standeman]

Ik weet niet of er mensen zijn die hier ervaring mee hebben, maar ik zit me het volgende af te vragen.

Hoe kan ik het best (privacy) gevoelige data versleutelen, opslaan en weer ontsleutelen?

Versimpeld voorbeeldje:
Er wordt een database aangelegd waarin user accounts zijn opgeslagen met medische informatie. Denk hierbij aan bepaalde aandoeningen en voedingspatronen.

Nu is het zaak dat bijvoorbeeld een iemand met db-access niet zomaar voor user X kan opzoeken waar hij allemaal last van heeft. Eigenlijk alleen de user en sommige instanties mogen die informatie inzien en voor alle andere mensen moet het onleesbaar zijn.

Op zich is het versleutelen van de data niet zo moeilijk. Je kiest een algoritme (3DES, AES, Blowfish), een keysize (behalve bij 3DES natuurlijk) en je versleuteld de data. Als je de data weer nodig hebt ontsleutel je het weer en toon het in de (web) applicatie.

Mijn vraag is eigenlijk hoe pak je het beste key-management aan:
* Hoe bepaal je beste sleutels (perfomance / security afweging)
* Wanneer verander je van sleutel? (Vertrek van bevoegde personen, als de sleutel compromised is)
* Hoe verander je het beste van sleutel?
* Waar laat je je sleutel (wat voor keystore)


Overigens zijn hardwarematige oplossingen (bijv. HSM's van Thales) voor ons een beetje te duur

[pedorus]

Standeman schreef op donderdag 20 mei 2010 @ 10:11:
* Hoe bepaal je beste sleutels (perfomance / security afweging)

Ik zou hier kiezen voor een decodering aan de client-side kant, op dezelfde manier als bij veel DRM-systemen. Eigenlijk zijn er dus 2 decoderingen, een met de eigen sleutel om de sleutel van de data te pakken te krijgen (uit tabel met sleutels, asymmetrisch versleuteld zodat je anderen toegang kan geven). Nog een om met de verkregen sleutel de data zelf te decoderen (uit tabel met data, symmetrisch versleuteld). Eenmaal gedecodeerd valt kopiëren natuurlijk nooit tegen te gaan, dit is de zwakte van DRM.

Aangezien de client meestal genoeg capaciteit heeft, is performance geen probleem. Alleen de benodigde data moet aan db-gebruikers met toegang worden overgezonden.

* Wanneer verander je van sleutel? (Vertrek van bevoegde personen, als de sleutel compromised is)

Goede vraag.
Voor de sleuteltabel:
Als de sleutel compromised is, of de gebruiker inmiddels ongeautoriseerd, de bijbehorende gecodeerde sleutels verwijderen.
Voor de data:
Bij nooit opgevraagde sleutels is er sowieso geen probleem (gewoon sleutels uit sleuteltabel verwijderen). Het probleem ontstaat als de sleutel wel is opgevraagd, maar de data niet. Dan zou je dit kunnen intrekken, maar eigenlijk zou dat nooit voor moeten komen, omdat ze altijd tegelijkertijd worden opgevraagd. Veranderen van sleutel voor de data zelf is eigenlijk meestal niet zo nuttig, aangezien de data dan zelf ook compromised kan zijn. Kortom: actie is alleen nodig als je ooit van algoritme wijzigt, maar dat is nogal lastig omdat je zelf niet de data kan decoderen.. Het zal dan stapsgewijs moeten.

* Hoe verander je het beste van sleutel?

Sleuteltabel wijzigen voor jouw sleutels. Jouw publieke sleutel wijzigen.
De sleutel voor de data zelf wijzigen is alleen nodig als blijkt dat het algoritme/de gebruikte sleutelgrootte niet meer veilig is.

* Waar laat je je sleutel (wat voor keystore)

In de sleuteltabel. Wel natuurlijk zijn rijen alleen opvraagbaar met normale datatoegang-checks (dus zoals hier op T.net), voor de zekerheid.

offtopic:
Is het handig om een 'prutser 1e klasse' hieraan te laten werken?

[H!GHGuY]

Kijk even naar PKI (public key infrastructure) en, omdat ze eigenlijk hetzelfde systeem oplossen, encryptie binnen digitale video broadcast (EMM, ECM, CAM enz.)

Als je die 2 combineert kom je denk ik al een heel eind:
- op de server codeer je met een master-key all data in de DB.
- bij een client request decode en re-encode je met de user public-key
- client decode met zijn private key de gegevens.

Als de re-encode een stap te ver is kun je de data opsturen en de key om de data te decoden geencodeerd met de public-key van de user, dus (data + encode(decode-key)).
Dit heeft natuurlijk nadelen dat eenmaal een user toegang tot een dossier heeft gehad, hij altijd opnieuw toegang kan hebben.

[Anoniem: 50683]

Standeman schreef op donderdag 20 mei 2010 @ 10:11:
Ik weet niet of er mensen zijn die hier ervaring mee hebben, maar ik zit me het volgende af te vragen.

Hoe kan ik het best (privacy) gevoelige data versleutelen, opslaan en weer ontsleutelen?

Versimpeld voorbeeldje:
Er wordt een database aangelegd waarin user accounts zijn opgeslagen met medische informatie. Denk hierbij aan bepaalde aandoeningen en voedingspatronen.

Nu is het zaak dat bijvoorbeeld een iemand met db-access niet zomaar voor user X kan opzoeken waar hij allemaal last van heeft. Eigenlijk alleen de user en sommige instanties mogen die informatie inzien en voor alle andere mensen moet het onleesbaar zijn.

Hierbij ga je er vanuit dat de medische informatie alszijnde "textuele" data wordt opgeslagen in de database.
Wat nu als dit nu niet zo eens maar op basis van relatietabellen gebeurd ?

[pedorus]

H!GHGuY schreef op donderdag 20 mei 2010 @ 12:48:
- op de server codeer je met een master-key all data in de DB.
- bij een client request decode en re-encode je met de user public-key

Op deze manier kan de databasebeheerder (in de categorie 'andere mensen') dus bij alle gegevens.

[Standeman]

pedorus schreef op donderdag 20 mei 2010 @ 12:23:
[...]

Ik zou hier kiezen voor een decodering aan de client-side kant, op dezelfde manier als bij veel DRM-systemen. Eigenlijk zijn er dus 2 decoderingen, een met de eigen sleutel om de sleutel van de data te pakken te krijgen (uit tabel met sleutels, asymmetrisch versleuteld zodat je anderen toegang kan geven). Nog een om met de verkregen sleutel de data zelf te decoderen (uit tabel met data, symmetrisch versleuteld). Eenmaal gedecodeerd valt kopiëren natuurlijk nooit tegen te gaan, dit is de zwakte van DRM.

Aangezien de client meestal genoeg capaciteit heeft, is performance geen probleem. Alleen de benodigde data moet aan db-gebruikers met toegang worden overgezonden.

Ah, dus bijv een RSA "master" public key om alle "user-keys" te versleutelen. Dan wanneer een user data opvraagt kan je de user-key decrypten en naar de client versturen (via bijv https) waarna de client lekker zijn eigen data kan decrypten.

Performance gaat dan waarschijnlijk wel een issue worden omdat de clients o.a. (smart)phones zijn.

[...]

Goede vraag.
Voor de sleuteltabel:
Als de sleutel compromised is, of de gebruiker inmiddels ongeautoriseerd, de bijbehorende gecodeerde sleutels verwijderen.
Voor de data:
Bij nooit opgevraagde sleutels is er sowieso geen probleem (gewoon sleutels uit sleuteltabel verwijderen). Het probleem ontstaat als de sleutel wel is opgevraagd, maar de data niet. Dan zou je dit kunnen intrekken, maar eigenlijk zou dat nooit voor moeten komen, omdat ze altijd tegelijkertijd worden opgevraagd. Veranderen van sleutel voor de data zelf is eigenlijk meestal niet zo nuttig, aangezien de data dan zelf ook compromised kan zijn. Kortom: actie is alleen nodig als je ooit van algoritme wijzigt, maar dat is nogal lastig omdat je zelf niet de data kan decoderen.. Het zal dan stapsgewijs moeten.

Ik zie even niet waarom ik zelf niet de data kan decoderen. Technisch gezien kan ik bij de private "master" key om zo de "user-keys" te ontcijferen...

[...]

Sleuteltabel wijzigen voor jouw sleutels. Jouw publieke sleutel wijzigen.
De sleutel voor de data zelf wijzigen is alleen nodig als blijkt dat het algoritme/de gebruikte sleutelgrootte niet meer veilig is.

[...]

In de sleuteltabel. Wel natuurlijk zijn rijen alleen opvraagbaar met normale datatoegang-checks (dus zoals hier op T.net), voor de zekerheid.

auditing is inderdaad ook een onderdeel van het verhaal, maar wilde ik vooralsnog even buiten deze discussie houden

offtopic:
Is het handig om een 'prutser 1e klasse' hieraan te laten werken?

offtopic:
Mhoaw, door mijn (beperkte) ervaring met o.a. FIPS-180 en de EMV specificatie ben ik de aangewezen persoon om een concept te benken. Vooralsnog is het alleen een haalbaarheidsonderzoek

Anoniem: 50683 schreef op donderdag 20 mei 2010 @ 13:00:
[...]

Hierbij ga je er vanuit dat de medische informatie alszijnde "textuele" data wordt opgeslagen in de database.
Wat nu als dit nu niet zo eens maar op basis van relatietabellen gebeurd ?

Ik ga nog even nergens vanuit. Het is nog volslagen onbekend met welke data structuren we te maken krijgen en hoe we dit precies gaan modelleren.

[pedorus]

Standeman schreef op donderdag 20 mei 2010 @ 16:22:
Ah, dus bijv een RSA "master" public key om alle "user-keys" te versleutelen.

Nee, er dus geen master key. Hooguit een master key per pakketje. Stel dat een client data wil opslaan, en al een publieke key heeft, dan is het proces:

• genereer nieuwe "data-key" voor data
• versleutel pakketje symmetrisch met data-key->datapakketje
• versleutel data-key asymmetrisch met eigen publieke key->sleutelpakketje
• Per instantie die toegang krijgt: versleutel data-key met publieke key van instantie->sleutelpakketje
• stuur datapakketje en sleutelpakketjes op naar server. Server kan data dus niet decrypten.

Hetgeen dat de client dus nodig heeft is een private key, en een mogelijkheid om bij de publieke keys en zijn sleutelpakketjes en datapakketjes in de db te komen.

En tsja, als je toegang met een client wil die zelf onvoldoende de-/encryptiecapaciteit heeft, dan zul je altijd een server moeten gaan vertrouwen..

[Standeman]

hmm, maar dan kan je wel problemen krijgen met je key management proces.

Als de private key van de client verloren gaat (stel client mobieltje dat gejat wordt), heb je dus een probleem omdat je de symmetrische data-key niet meer kan decrypten.

hmmm, lastig. Ik snap het wel, maar ik begrijp het nog niet helemaal

[pedorus]

Standeman schreef op vrijdag 21 mei 2010 @ 15:20:
Als de private key van de client verloren gaat (stel client mobieltje dat gejat wordt), heb je dus een probleem omdat je de symmetrische data-key niet meer kan decrypten.

Tsja, er is een reden dat TrueCrypt om nogal lange wachtwoorden vraagt. Je zult altijd ergens de entropie voor de sleutel vandaan moeten halen.

[Standeman]

Maar in een (commerciële) consumenten applicatie gaat het niet werken wanneer iemand z'n key kwijt is dat niemand never nooit meer bij zijn data kan komen. Keys en zelfs de devices gaan kwijtgeraakt worden, dus is het wel een interessante vraag hoe je daar het beste mee omgaat.

[Herko_ter_Horst]

Volgens mij worden er hier twee zaken doorelkaar gehaald, namelijk encryptie en autenticatie/autorisatie.

Encryptie zorgt voor een veilige opslag van de gegevens: zonder key is de informatie onleesbaar, ook voor een applicatie of beheerder.

Authenticatie/autorisatie bepaalt wie welke gegevens mag bekijken (autorisatie) aan de hand van credentials (authenticatie). Credentials kunnen bestaan uit een username/password, maar het kan ook een key of certificate zijn. Zo'n key zal in het algemeen NIET de key zijn waarmee de gegevens zijn ge-encrypt. De key dient in dit geval namelijk om de gebruiker te identificeren en niet om de gegevens mee te decrypten.

Als je de gegevens ge-encrypt wilt opslaan (wat me op zich verstandig lijkt), zal er een applicatie moeten zijn die de gegevens can decrypten om deze aan de gebruiker aan te bieden (deze applicatie heeft dus de beschikking over de key waarmee de gegevens gedecrypt kunnen worden). De applicatie bepaalt aan de hand van de autorisatiegegevens (ACL of ander mechanisme) of de gebruiker het recht heeft deze gegevens in te zien, decrypt vervolgens de gegevens en biedt die aan de gebruiker aan.

Overigens: ik heb hierbij een client-server architectuur in gedachten. Als alles geheel stand-alone op een client moet draaien, krijg je het m.i. niet waterdicht. Als de server(-applicatie) voor de encryptie/decryptie en authenticatie/autorisatie zorgt, krijg je het wel veilig bij de clients (mits je credentials veilig genoeg zijn).

[ Voor 3% gewijzigd door Herko_ter_Horst op 25-05-2010 16:00 ]