[PHP] Public/Private key encryption, hoe private key bewaren

[Barryvdh]

Ik was bezig met het uitzoeken van assymetrische encryptie in PHP en hoopte dat iemand feedback zou kunnen geven of misschien wat tips had.

Situatie: Gebruikers van de applicatie moeten elkaar berichten/bestanden kunnen sturen, die niet door anderen geopend kunnen worden. Dus ook niet door de programmeur/sysadmin/hacker die root toegang heeft etc. Maar moet transparant zijn voor de gebruiker, dus niet zelf keys laten beheren ed.

Voorgestelde oplossing: Assymetrische encryptie op basis van public/private keys, zodat alleen de gebruiker voor wie het bedoeld is, het bestand kan lezen. Private key wordt in de database (of evt. filesystem) opgeslagen, met een passphrase/encryptie op basis van het wachtwoord van de gebruiker. Zonder het wachtwoord is het bestand dus niet decrypten, ook niet voor de systeembeheerder.

Vraag: Hoe blijft het systeem gebruiksvriendelijk, terwijl het nog wel veilig is? Het liefst vul je maar 1 keer je wachtwoord in, niet elke keer als je een bestand wil lezen. En als je je wachtwoord vergeet, ben je al je data kwijt..

Overwegingen:
Data opslaan in een sessie kan, maar in principe is dat ook file-based (of een andere database driver), maar in het geval van een hack zou de hacker die bestanden dus ook kunnen benaderen.
Dus idealiter zou je passphrase (of private key) bij de gebruiker bewaren.

Opslaan in cookies?
Ik ga uit van een applicatie op basis van Laravel, waarbij Cookies encrypted zijn, secure en http only.
Aangezien de cookies encrypted zijn, zouden we zodra de gebruiker inlogt, de passphrase kunnen decrypten met het gebruikerswachtwoord en opslaan in een cookie. (Wat waarschijnlijk efficiënter is als de hele key in de cookie bewaren, aangezien het met elke request meegestuurd wordt)
Is dit wel veilig? (Natuurlijk niet als de gebruiker zowel toegang heeft tot de user-cookies als root-toegang tot het systeem, maar dat lijkt me geen reëel scenario)

Key recovery?
Aangezien het wachtwoord de sleutel is, kan je niet meer bij je bestanden als je je wachtwoord vergeet. Een oplossing zou zijn om de passphrase ook te encrypten met een random string. Die random string mailen/geven we dan aan de gebruiker bij het registreren om zelf veilig te bewaren. In het geval van verlies van data kan die key gebruikt worden om alsnog bij je data te kunnen. (Al zal hier misschien een soort combinatie van e-mail validatie bij moeten zitten, anders komt het neer op het opschrijven van je wachtwoord)

Dus dan zou het er in de database zoiets uitzien:
table users
- id, email, name, password_hash etc
- public_key (plaintext)
- private_key (plaintext, beveiligd met passphrase)
- passphrase_encrypted (encrypted met user password)
- passphrase_recovery (zelf passphrase, maar encrypted met random string)

passphrase zelf is dan gewoon een random string van xx tekens die gegeneerd wordt bij aanmaken van de account.

Bij registreren:
- Random passphrase maken
- Passphrase encrypten met gekozen wachtwoord
- Passprhase encrypten met random recovery string, mailen naar gebruiken

Bij aanmaken bestand/bericht
- Ophalen public_key van doelgebruiker(s)
- Bericht encrypten met public key

Bij inloggen
- Ophalen passphrase, decrypten met wachtwoord
- Decrypted passphrase bewaren in (beveiligd) cookie

Bij lezen bericht
- Passphrase uit cookie halen
- Bericht decrypten met private key en passphrase.

Bij wijzigen wachtwoord
- passphrase decrypten met oude wachtwoord
- passphrase encrypten met nieuwe wachtwoord.
- Keys en passphrase blijven zelfde, dus bestanden intact.

Bij vergeten wachtwoord
- Extra optie voor invullen recovery code. Indien aanwezig, code gebruiken om passphrase te decrypten. Opnieuw encrypten met nieuwe wachtwoord. Bestanden zijn intact.
- Anders nieuwe public/private key pair maken. Bestanden zijn verloren.

Implementatie zou dan zijn op basis van openssl_seal of de Zend OpenSSL Filter, die als wrapper dient voor OpenSSL seal/open.

[gekkie]

Dus:
A ) het bericht wat geencrypt moet worden is sowieso al (tijdelijk) niet encrypted aanwezig op de server ...
B ) ook de private key is (tijdelijk) aanwezig op de server om het bericht te encrypten ...

De enige manier waarop je iets echt veilig maken is als zowel het bericht als de private key als de encryptie gebeurd in een door de gebruiker beheerde veilige omgeving door geverifieerde software. Daarmee is het ook gelijk verduveld lastig om er een dienst mee te beginnen ben ik bang.

Uiteraard kun je dan compromissen gaan maken, maar eigenlijk haal je met enige wijziging al gauw alles onderuit.
Mijnsinziens is het dus ook (helaas) onmogelijk om:
A ) het makkelijk en transparant te maken voor de gebruiker
B ) de last van het verzorgen van een veilige en geverifieerde omgeving voor de encryptie over te kunnen nemen van de gebruiker.

(semi)-veilige tunnels gebruiken we allemaal al dagelijks, het probleem zit hem in de end-points.
op fosdem was er wel een aardige poging door zowel keys als encryptie op de GPU plaats te laten vinden, waarbij het uitlezen hiervan bemoeilijkt wordt als een server gehackt zou worden, er kwamen echter al snel weer enige omissies aan het licht .. kwetsbaar moment na boot als de keys toch geladen moeten worden naar de GPU ... wat staan GPU's toe bij firmwareupdate mechanismen etc.

[ Voor 21% gewijzigd door gekkie op 22-02-2015 12:09 ]

[Barryvdh]

Klopt dat het bericht/key tijdelijk op de server is, maar dat gebeurt in principe in memory:
- De key wordt niet opgeslagen op de server, alleen in de cookie bij de gebruiker. Daarna in het geheugen voor de duur van de request.
- De bestanden zijn niet heel groot. In principe wordt het bestand/bericht encrypted ingelezen. Dan volgt de decryptie in geheugen en wordt het bestand ge-output naar de gebruiker via PHP, dus er wordt niet een los bestand naar het filesystem geschreven.

In principe is het dan natuurlijk nog wel mogelijk dat iemand met root-access mee zou kunnen luisteren, door ook een kopie naar hemzelf te sturen zodra het decrypted is. Maar je zou iig niet bij bestanden kunnen die al op de server staan als je een momentopname van de server hebt.

Het voornaamste doel hier is om te zorgen dat iemand met toegang tot de server alle bestanden kan decrypten. Dat is met symmetrische encryptie wel, omdat je de decryptie key ook ergens moet bewaren.

[ Voor 11% gewijzigd door Barryvdh op 22-02-2015 12:26 ]

[azerty]

Is een service zoals mega niet mogelijk? Waar de encryption/decryption met javascript aan de client-side gebeurd? De keys zou je dan in de localstorage van de browser kunnen bewaren....

[Barryvdh]

wsitedesign schreef op zondag 22 februari 2015 @ 12:45:
Is een service zoals mega niet mogelijk? Waar de encryption/decryption met javascript aan de client-side gebeurd? De keys zou je dan in de localstorage van de browser kunnen bewaren....

Dat zou eventueel kunnen, maar heeft niet mijn voorkeur omdat de rest allemaal in PHP is javascript niet mijn beste taal is. Al zou dat wel een optie kunnen zijn, bijv. met https://github.com/travist/jsencrypt
Weet alleen niet of dat handig is met pdf's enzo.

Mijn voorkeur voor nu zou zijn om binnen PHP te blijven. Zien jullie problemen, buiten het meeluisteren als de server helemaal gekraakt is?

[azerty]

Grote bestanden met asymmetrische versleuteling versleutelen en ontsleutelen kan traag zijn (natuurlijk volledig afhankelijk van hoe groot je bestanden zijn).

Een opzet in de vorm als volgt zou misschien een betere/snellere optie zijn dan:

- Gebruik symmetrische versleuteling (snel) om het bestand te versleutelen met een random generated key
- Gebruik de asymmetrische (trage) versleuteling om de kleine symmetrische sleutel te versleutelen

Ik geloof dat vrij veel diensten op deze manier werken

[Barryvdh]

Dat klopt inderdaad, maar dat is wat openssl_seal ook doet. Als je een bestand encrypt, gebruikt hij symmetrische encryptie om het bestand te versleuten. De key bewaart hij in een envelope, die encrypt wordt met de public key. Bij meerdere keys heb je dus meerdere envelopes. (Al kan ZendFilter ze samen met het bestand opslaan zodat je ze niet los hoeft op te slaan.)

[ Voor 23% gewijzigd door Barryvdh op 22-02-2015 13:27 ]

[azerty]

Ik had nog niet gekeken naar de links, my bad

[gekkie]

Barryvdh schreef op zondag 22 februari 2015 @ 12:24:
Klopt dat het bericht/key tijdelijk op de server is, maar dat gebeurt in principe in memory:
- De key wordt niet opgeslagen op de server, alleen in de cookie bij de gebruiker. Daarna in het geheugen voor de duur van de request.
- De bestanden zijn niet heel groot. In principe wordt het bestand/bericht encrypted ingelezen. Dan volgt de decryptie in geheugen en wordt het bestand ge-output naar de gebruiker via PHP, dus er wordt niet een los bestand naar het filesystem geschreven.

In principe is het dan natuurlijk nog wel mogelijk dat iemand met root-access mee zou kunnen luisteren, door ook een kopie naar hemzelf te sturen zodra het decrypted is. Maar je zou iig niet bij bestanden kunnen die al op de server staan als je een momentopname van de server hebt.

Het voornaamste doel hier is om te zorgen dat iemand met toegang tot de server alle bestanden kan decrypten. Dat is met symmetrische encryptie wel, omdat je de decryptie key ook ergens moet bewaren.

Je wil dus in principe dezelfde veiligheid als met passwords hashen .. als je server gehackt wordt ligt niet alles gelijk op straat .. maar alleen het deel wat geencrypt is met keys waarmee users na de hack nog zijn ingelogd (die kun je immers afvangen).

Dus je assumptie is dat:
- Je server in principe veilig is
- Als er dan toch een breach is, deze bijna direct opgemerkt wordt.
- Gebruikers hierop moeten en willen vertrouwen.

Javascript schiet je ook maar beperkt wat mee op, als ik je server onder controle heb, die ook de javascript zelf uit serveert .. kan ik die natuurlijk veranderen naar geef mij gewoon de plaintext invoer.

Mijn voorkeur voor nu zou zijn om binnen PHP te blijven. Zien jullie problemen, buiten het meeluisteren als de server helemaal gekraakt is?

potentieel nog zaken als XSS etc., als er dus iets clientside het password wat je invoert weet af te snoepen en/of zwakheden in een van de andere schakels (ssl)
Het geheel blijft zo sterk als de zwakste schakel .. en opzich introduceer je redelijk wat schakels die moeten functioneren.
En er valt opzich mee te leven als de leverancier bijvb aansprakelijk is, wij pinnen nog vrolijk omdat we meestal schadeloos gesteld worden. Maar ook daar kun je met een camera of opgeplakt keypadje prima de sleutels binnenhalen. Wel moet je dan ook de chip nog bemachtigen, maar ook hier heb je als eindgebruiker maar weinig zicht en controle over de omgeving waarin je je key afstaat.

[ Voor 19% gewijzigd door gekkie op 22-02-2015 15:22 ]

[Barryvdh]

gekkie schreef op zondag 22 februari 2015 @ 15:16:
[...]

Je wil dus in principe dezelfde veiligheid als met passwords hashen .. als je server gehackt wordt ligt niet alles gelijk op straat .. maar alleen het deel wat geencrypt is met keys waarmee users na de hack nog zijn ingelogd (die kun je immers afvangen).

Dus je assumptie is dat:
- Je server in principe veilig is
- Als er dan toch een breach is, deze bijna direct opgemerkt wordt.
- Gebruikers hierop moeten en willen vertrouwen.

Javascript schiet je ook maar beperkt wat mee op, als ik je server onder controle heb, die ook de javascript zelf uit serveert .. kan ik die natuurlijk veranderen naar geef mij gewoon de plaintext invoer.

Klopt, maar in principe kan je dat niet echt afvangen, behalve door de bestanden versleuteld naar de gebruiker te sturen, en de gebruiker zelf zijn private key laten bewaren en met standaard (betrouwbare) software laat decrypten. Maar dat is niet echt praktisch voor de gemiddelde gebruiker.

[gekkie]

Barryvdh schreef op zondag 22 februari 2015 @ 15:19:
[...]
Klopt, maar in principe kan je dat niet echt afvangen, behalve door de bestanden versleuteld naar de gebruiker te sturen, en de gebruiker zelf zijn private key laten bewaren en met standaard (betrouwbare) software laat decrypten. Maar dat is niet echt praktisch voor de gemiddelde gebruiker.

Check .. vandaar dat echte encryptie niet makkelijk en transparant te maken is en al helemaal niet server-side.
(en alles wat er is, dus een groot compromis is (wat vaak wordt weggestopt achter ontzettend grote keys en meer techno-brabbel, wat ik dan weer kwalijk vind .. compromis is opzich niet erg, maar als je dan toch zo makkelijk en transparant wil zijn, leg dan ook uit waar je wel en niet tegen beschermd.)

Bovenstaande zorgt er dus wel voor dat de last voor de encryptie en bescherming van de keys meer bij de gebruiker zelf komt te liggen, maar ook de mogelijkheden tot controle over de omgeving en de gebruikte encryptie. Als ik echt iets zou willen encrypten zou ik het dus altijd zelf door gpg halen en nimmer op een dienst vertrouwen.

Overigens is dat op elke computer zo, want wie controleert er alle miljoenen lijnen code ( en die via updates etc nog extra binnen komt) ? En wat er vervolgens als dan niet geencrypt via het netwerk de tent weer verlaat ?
Dus ook clientside is het nog steeds verdraaid lastig .. een stap verder kom je bij yubi-keys .. 2 factor auth etc uit. Waarmee je het steeds complexer maakt voor iemand om je keys te bemachtigen en er iets mee te kunnen.

[ Voor 32% gewijzigd door gekkie op 22-02-2015 15:33 ]

[johnkeates]

Je moet de asymmetrische key met een symmetrische sleutel coderen. Doe het zoals LUKS het doet:

- Je asymmetrische lange/sterke key laat je lekker op de server staan
- Gebruik iets als AES om de key te versleutelen zodat hij bij een gehackte server niet bruikbaar is
- Gebruik het wachtwoord van de gebruiker om de AES-gecodeerde sleutel te decoderen, in-memory

Nu zorgt LUKS er voor dat het opslaan van keys tijdens bewerkingen niet in RAM gaat maar in CPU registers om dat RAM te lezen is bij fysieke inbraak en CPU registers niet. Dat gaat je met PHP waarschijnlijk niet lukken.

Tweede optie: gebruik user-side certificaten met private keys. Eindgebruiker is zelf verantwoordelijk voor z'n keys...

[Barryvdh]

gekkie schreef op zondag 22 februari 2015 @ 15:26:
[...]

Check .. vandaar dat echte encryptie niet makkelijk en transparant te maken is en al helemaal niet server-side.
(en alles wat er is, dus een groot compromis is (wat vaak wordt weggestopt achter ontzettend grote keys en meer techno-brabbel, wat ik dan weer kwalijk vind .. compromis is opzich niet erg, maar als je dan toch zo makkelijk en transparant wil zijn, leg dan ook uit waar je wel en niet tegen beschermd.)

Klopt maargoed, het hangt natuurlijk af van de mate van gevoeligheid en de afwegingen die je maakt.

johnkeates schreef op zondag 22 februari 2015 @ 15:32:
Je moet de asymmetrische key met een symmetrische sleutel coderen. Doe het zoals LUKS het doet:

- Je asymmetrische lange/sterke key laat je lekker op de server staan
- Gebruik iets als AES om de key te versleutelen zodat hij bij een gehackte server niet bruikbaar is
- Gebruik het wachtwoord van de gebruiker om de AES-gecodeerde sleutel te decoderen, in-memory

Nu zorgt LUKS er voor dat het opslaan van keys tijdens bewerkingen niet in RAM gaat maar in CPU registers om dat RAM te lezen is bij fysieke inbraak en CPU registers niet. Dat gaat je met PHP waarschijnlijk niet lukken.

Tweede optie: gebruik user-side certificaten. Eindgebruiker is zelf verantwoordelijk voor z'n keys...

Dat is in principe dus ook wat ik voorstel volgens mij, alleen zou PHP het dus wel in zijn RAM opslaan, maar dan is het weer het geval dat de aanvaller al volledige toegang moet hebben tot het systeem, toch?

Zodra een aanvaller rechtstreekse controle heeft, is het natuurlijk ook niet ingewikkeld om het wachtwoord af te luisteren tijdens het inloggen, en hebben verdere lagen dus ook weinig zin meer..

[gekkie]

Barryvdh schreef op zondag 22 februari 2015 @ 15:37:
[...]
Klopt maargoed, het hangt natuurlijk af van de mate van gevoeligheid en de afwegingen die je maakt.

En zolang je daar maar eerlijk over bent. De serverbeheerder kan dus overal bij eventueel gedwongen door een rechter, in iedergeval nadat je weer je password gebruikt.

Dat is in principe dus ook wat ik voorstel volgens mij, alleen zou PHP het dus wel in zijn RAM opslaan, maar dan is het weer het geval dat de aanvaller al volledige toegang moet hebben tot het systeem, toch?

Zodra een aanvaller rechtstreekse controle heeft, is het natuurlijk ook niet ingewikkeld om het wachtwoord af te luisteren tijdens het inloggen, en hebben verdere lagen dus ook weinig zin meer..

Yups .. en daarom moet je dus nog steeds jou en jouw server kunnen vertrouwen, het enige wat je beperkt is de mate van gevolgen van een kort durende breach.

Het is ook niet voor niets dat die geencrypte email-service in de VS offline ging toe ze van de rechters de keys op moesten geven zonder er ruchtbaarheid aan te mogen geven. Het enige wat ze konden doen was de stekker eruit trekken voor hun gebruikers.

[ Voor 11% gewijzigd door gekkie op 22-02-2015 15:46 ]

[johnkeates]

Als iemand keys uit RAM wil lezen zijn er drie manieren:

1. root rechten krijgen
2. DMA attack
3. Cold boot attack

In het 1e geval is het mogelijk het op afstand te doen, in de andere twee gevallen is het alleen met fysieke toegang mogelijk en in het 3e geval moet de server zelfs uit.


Oplossing: geen keys op de server, dus client-side encryption. Misschien moet je gewoon 'normale' methodes zoals encrypted email gebruiken? GPG op je mail en gaan. Er zijn vast al wel webmail systemen met GPG plugins die je daar voor kan gebruiken die client-side draaien.

Probleem in dit geval is natuurlijk dat je de client systemen moet vertrouwen dat ze hun keys niet lekken.


Al met al komt het voornamelijk op het volgende neer:

- Waar moet de verantwoordelijkheid liggen
- Welke kant van het verhaal kan je het beste beheersen/beveiligen
- Hoe 'moeilijk' mag het gebruik zijn, a.k.a., is client software vereisen een optie?
- Welke garanties moet je geven

Verder ga je als je je keys nooit in RAM of on-disk wil hebben een probleem met schaalbaarheid hebben om dat je CPU registers niet echt heel veel op kunnen slaan en je dus maar een paar keys tegelijk kan gebruiken voor encryptie/decryptie. Zonder custom hardware kom je er dan niet als je veel gebruikers hebt.

[Thralas]

Laten we het 'probabilistic confidentiality' noemen: je data is veilig, tenzij we compromised zijn en dat wel-of-niet doorhebben...

Ik zou er nog eens goed over nadenken wat de toegevoegde waarde van een hypothetische oplossing nu werkelijk is.

En als je dan toch besluit dat je niet om een halfslachtig systeem heen kunt, gebruik dan alsjeblieft iets dat PGP clientside implementeert, met iedere zelfbedachte oplossing schiet je jezelf gegarandeerd in de voeten, met PHP heb je mogelijk nog een soort uitstel van executie.

Google's end-to-end probeert het onderliggende probleem overigens aan te pakken, maar dat project is nog in alphafase en Chrome-only..

[ Voor 4% gewijzigd door Thralas op 22-02-2015 15:58 ]

[gekkie]

johnkeates schreef op zondag 22 februari 2015 @ 15:51:
Als iemand keys uit RAM wil lezen zijn er drie manieren:

1. root rechten krijgen
2. DMA attack
3. Cold boot attack

In het 1e geval is het mogelijk het op afstand te doen, in de andere twee gevallen is het alleen met fysieke toegang mogelijk en in het 3e geval moet de server zelfs uit.


Oplossing: geen keys op de server, dus client-side encryption. Misschien moet je gewoon 'normale' methodes zoals encrypted email gebruiken? GPG op je mail en gaan. Er zijn vast al wel webmail systemen met GPG plugins die je daar voor kan gebruiken die client-side draaien.

Probleem in dit geval is natuurlijk dat je de client systemen moet vertrouwen dat ze hun keys niet lekken.


Al met al komt het voornamelijk op het volgende neer:

- Waar moet de verantwoordelijkheid liggen
- Welke kant van het verhaal kan je het beste beheersen/beveiligen
- Hoe 'moeilijk' mag het gebruik zijn, a.k.a., is client software vereisen een optie?
- Welke garanties moet je geven

Verder ga je als je je keys nooit in RAM of on-disk wil hebben een probleem met schaalbaarheid hebben om dat je CPU registers niet echt heel veel op kunnen slaan en je dus maar een paar keys tegelijk kan gebruiken voor encryptie/decryptie. Zonder custom hardware kom je er dan niet als je veel gebruikers hebt.

Hier de slides van de FOSDEM presentatie met een GPU oplossing:
https://fosdem.org/2015/s...pixelvault_fosdem2015.pdf
al blijf je problemen houden met het moment van laden van keys in de gpu on boot etc.

Thralas schreef op zondag 22 februari 2015 @ 15:56:
Laten we het 'probabilistic confidentiality' noemen: je data is veilig, tenzij we compromised zijn en dat wel-of-niet doorhebben...

Ik zou er nog eens goed over nadenken wat de toegevoegde waarde van een hypothetische oplossing nu werkelijk is.

En als je dan toch besluit dat je niet om een halfslachtig systeem heen kunt, gebruik dan alsjeblieft iets dat PGP clientside implementeert, met iedere zelfbedachte oplossing schiet je jezelf gegarandeerd in de voeten, met PHP heb je mogelijk nog een soort uitstel van executie.

Google's end-to-end probeert het onderliggende probleem overigens aan te pakken, maar dat project is nog in alphafase en Chrome-only..

Mjah dit was uiteindelijk ook mijn conclusie toen ik mijn hersens hierop gekraakt heb .. je lijkt een eind op weg .. zeker als je allerlei implementatie techniek erbij bedenkt .. het lijkt heel wat ... totdat er dan een compromise is .. en alles eigenlijk stukje bij beetje weer in elkaar dondert.
En clientside pgp .. tsja .. gebruik dan ook in iedergeval een lib .. en vertrouwen je gebruikers je clientside implementatie wel. Bij chrome is dat wellicht ook een probleem .. zou ik chrome met alles wat erin zit en wekelijks geupdate wordt eigenlijk wel willen vertrouwen om daar in een dialog box m'n passphrase in te kloppen ? (opzich voor 99.999% van de dingen die ik doe wel .. ik ga er eigenlijk al vanuit dat alles wat ik op een computer doe gebruikt zou kunnen worden door derden .. ik hoop het niet ... en ben dan uiteraard nog steeds met een hoop dingen de sjaak .. maar ik maak me dan ook volstrekt geen illusies)

[ Voor 33% gewijzigd door gekkie op 22-02-2015 16:06 ]

[johnkeates]

gekkie schreef op zondag 22 februari 2015 @ 16:00:
[...]

Hier de slides van de FOSDEM presentatie met een GPU oplossing:
https://fosdem.org/2015/s...pixelvault_fosdem2015.pdf
al blijf je problemen houden met het moment van laden van keys in de gpu on boot etc.

Die heb je inderdaad ook nog. Heb je wel een GPU nodig
Om het nog even toe te voegen aan alles: een TPM is ook de oplossing niet. Die dingen zijn niet te vertrouwen, niet perse veilig en ook totaal niet praktisch.

Los daar van: wat je ook gaat doen, als je iets met security doet en SSL hebt, zorg dan dat je SSL implementatie dan ook daadwerkelijk veilig is! Dus pinning, stapling, lokale CA caches, geen onveilige SSL opties toestaan (dus eigenlijk: SSL niet toestaan, TLS wel enz. zie diverse sites en kijk ook bij qualys naar je SSL score voor een ruwe indicatie).

[ Voor 21% gewijzigd door johnkeates op 22-02-2015 16:03 ]

[Barryvdh]

Thralas schreef op zondag 22 februari 2015 @ 15:56:
Laten we het 'probabilistic confidentiality' noemen: je data is veilig, tenzij we compromised zijn en dat wel-of-niet doorhebben...

Ik zou er nog eens goed over nadenken wat de toegevoegde waarde van een hypothetische oplossing nu werkelijk is.

En als je dan toch besluit dat je niet om een halfslachtig systeem heen kunt, gebruik dan alsjeblieft iets dat PGP clientside implementeert, met iedere zelfbedachte oplossing schiet je jezelf gegarandeerd in de voeten, met PHP heb je mogelijk nog een soort uitstel van executie.

Google's end-to-end probeert het onderliggende probleem overigens aan te pakken, maar dat project is nog in alphafase en Chrome-only..

Uitgangspunt is dat er bij een lek of code-audit aangetoond moet kunnen worden dat er tot op zeker hoogte voldoende aandacht besteed is aan de beveiliging. In principe op basis van de richtlijnen van het Nationaal Cyber Security Centrum: https://www.ncsc.nl/diens...-voor-webapplicaties.html

quote: Deel 2, Hoofdstuk 7

B5-3.
Sla gevoelige gegevens versleuteld of gehashed op. Zorg ook voor versleuteling op webapplicatieniveau, door gebruik te maken van versleuteling of hashing in de database en/of bestanden.

In principe zou ik daaraan waarschijnlijk ook voldoen met symmetrische encryptie, omdat een aanvaller met een kopie van de bestanden, alleen encrypted files heeft.
Alleen als iemand toegang heeft tot die map, is het ook aanneembaar dat hij de applicatie key kan uitlezen en met wat programmeerwerk alsnog de bestanden kan uitlezen.

In principe is het onderliggende systeem niet 'zelfbedacht', het is de standaard OpenSSL seal/open functionaliteit die juist hiervoor gemaakt is. Het probleem is alleen hoe je de keys ed. opslaat.

De 'hypothetische oplossing' zou er dus voor zorgen dat je met een dump van de hardeschijf (uitlekken van backup? Systeembeheerder die stiekem een kopietje maakt?) alsnog niets aan de bestanden hebt, omdat er geen manier is om de private keys te gebruiken, zonder het wachtwoord van de gebruiker zelf.

Mijn inziens is het dus wel een stap beter beveiligd met assymetrische encryptie, ook al loop je tegen beperkingen aan waardoor je het nooit helemaal 100% kan afdekken tegen misbruik van root-toegang.

[gekkie]

Barryvdh schreef op zondag 22 februari 2015 @ 16:25:
[...]
Uitgangspunt is dat er bij een lek of code-audit aangetoond moet kunnen worden dat er tot op zeker hoogte voldoende aandacht besteed is aan de beveiliging. In principe op basis van de richtlijnen van het Nationaal Cyber Security Centrum: https://www.ncsc.nl/diens...-voor-webapplicaties.html
[...]
In principe zou ik daaraan waarschijnlijk ook voldoen met symmetrische encryptie, omdat een aanvaller met een kopie van de bestanden, alleen encrypted files heeft.
Alleen als iemand toegang heeft tot die map, is het ook aanneembaar dat hij de applicatie key kan uitlezen en met wat programmeerwerk alsnog de bestanden kan uitlezen.

In principe is het onderliggende systeem niet 'zelfbedacht', het is de standaard OpenSSL seal/open functionaliteit die juist hiervoor gemaakt is. Het probleem is alleen hoe je de keys ed. opslaat.

De 'hypothetische oplossing' zou er dus voor zorgen dat je met een dump van de hardeschijf (uitlekken van backup? Systeembeheerder die stiekem een kopietje maakt?) alsnog niets aan de bestanden hebt, omdat er geen manier is om de private keys te gebruiken, zonder het wachtwoord van de gebruiker zelf.

Mijn inziens is het dus wel een stap beter beveiligd met assymetrische encryptie, ook al loop je tegen beperkingen aan waardoor je het nooit helemaal 100% kan afdekken tegen misbruik van root-toegang.

Als er alleen bestanden lekken en geen keys dan is er inderdaad weinig aan de hand in dat geval.
Dus vooral in het gevalletje opendir .. of unencrypted backup in de webroot mikken etc. beperk je de gevolgen.

Bij die systeembeheerder die stiekem een kopietje maakt wordt het dus al lastiger, daar beperk je dus alleen de schade tot de tijdsspanne waarin de systeembeheerder start met dingen te doen die niet de bedoeling zijn .. en wanneer je er achter komt en dit stopt, iedereen die in die tijdsspanne zijn wachtwoord in klopt is potentieel met terugwerkende kracht de sjaak.

Belangrijkste hiervoor is niet zozeer de wijze van encrypten, maar meer dat de key/passphrase uniek is per gebruiker en dus niet geshared is.

Het probleem zit hem inderdaad in de overdracht (en dan vooral het stukje voor (client side) en net na de TLS tunnel), (tijdelijke) opslaan van je passphrase/keys en de encryptie/decryptie routine zelf

En er is volgens mij geen mogelijkheid dit geheel te ondervangen, hooguit lastiger te maken door zaken in hardware te gieten, onder de assumptie dat die deugdelijk is en lastiger te compromiteren behalve met fysieke toegang. Probleem daarmee is dan weer dat als er iets niet deugdelijk blijkt, de hardware gelijk waardeloos is)

(en dan zijn we nog niet eens begonnen over het uitlezen van keys doormiddel van cpu latency etc etc en weet ik het wat al niet meer onderzocht is)