[PHP] Public/Private key encryptie / signing

[Zeezicht]

Ik zoek een manier om bepaalde berichten (evt. ook bestanden) te signen in PHP. Dit om een soort digitale handtekening eronder te zetten. Het zou dan met de private key ondertekend moeten worden en de met de public key moet je kunnen controleren of dat klopt.

Op internet kom je alleen voorbeelden tegen die gebruik maken van PGP / GPG keys in je homedir of van OpenSSL oplossingen met ook weer keys ergens op schijf. Ik wil het eigenlijk compleet via PHP doen om zo die keys te omzeilen en gewoon een key in laten vullen via een form. Zijn er mensen die hiermee ervaring hebben? Of eventueel bestaande classes die ik niet heb kunnen vinden...

[DroogKloot]

Er is een reden dat private keys private worden genoemd. Gebruikers horen die dingen niet in een form in te moeten vullen, dat gaat namelijk nogal voorbij aan het idee van PKC.

[Zeezicht]

Daar heb je een goed punt. Maar met GPG moet ik bijv. die key ook hebben in de homedir, dus dat is dan ook niet echt een oplossing.
Is er dan een soort challenge response oplossing waarbij ze de response invullen?

[DroogKloot]

Dat GPG keys lokaal opslaat is een noodzakelijk kwaad (er zijn nou eenmaal bijzonder weinig mensen die hun sleutels uit het hoofd kunnen opdreunen), maar het cruciale verschil is dat de (private) keys nooit worden verstuurd (ie. nooit de machine verlaten) en dat voor alle sign- en decrypt-operaties bovendien nog een passphrase moet worden ingevoerd. Wat jij daarentegen voorstelt staat zowat gelijk aan de private key openbaar maken, kortom geen goed plan.

[Zeezicht]

Ja dat snap ik, maar hoe kan je het dan voor een website doen? Dus een bepaalde string kunnen signen. Dat zou dan alleen met iets van challenge respone kunnen dan, lijkt me?

[DexterDee]

Je zou voor een tekstbericht een checksum kunnen maken voor het bericht. Die zet je vervolgens onderin het bericht met een bepaalde notatie, bijv. [signed:673a79ba37c6a76b367bcaa37bcc7a3]. Vervolgens geef je automatisch of handmatig de mogelijkheid om de tekst + checksum te valideren op jouw site. Bijv. door een knopje ("Validate signed message") te maken die een form op jouw website post met de tekst + checksum. Jouw server kan dan middels de private key de echtheid checken. OF je doet het handmatig met een formulier op jouw website waarin je de tekst kan pasten. Kan ook met bestanden, alleen is dat net iets ingewikkelder, omdat die naar de server gestuurd moeten worden.

[DroogKloot]

De string client-side signen en dan senden is de enige oplossing die daar min of meer acceptabel voor is, imo.

[Zeezicht]

DexterDee schreef op vrijdag 01 september 2006 @ 20:18:
Je zou voor een tekstbericht een checksum kunnen maken voor het bericht. Die zet je vervolgens onderin het bericht met een bepaalde notatie, bijv. [signed:673a79ba37c6a76b367bcaa37bcc7a3]. Vervolgens geef je automatisch of handmatig de mogelijkheid om de tekst + checksum te valideren op jouw site. Bijv. door een knopje ("Validate signed message") te maken die een form op jouw website post met de tekst + checksum. Jouw server kan dan middels de private key de echtheid checken. OF je doet het handmatig met een formulier op jouw website waarin je de tekst kan pasten. Kan ook met bestanden, alleen is dat net iets ingewikkelder, omdat die naar de server gestuurd moeten worden.

Het gaat erom dat ik zelf kan controleren dat iemand anders (een bekend persoon) dat bericht heeft gepost en ondertekend. Dus niet dat iemand mijn berichten kan checken.
Maar zo'n checksum is mss wel een idee. Die geef je aan die persoon en dan moet die 'm zelf signen met zijn private key, en de uitkomst kan hij dan posten. En die kan ik dan controleren of het van hem komt.
Probleem is alleen hoe werkt zo'n public / private key?

[martijn_brinkers]

Op zich is het mogelijk om client side documenten etc. digitaal te laten ondertekenen. De private key kan dan zelfs op een smartcard of USB token staan. Het is echter wel zo dat je gebruik moet maken van een browser die dat ondersteund (het is niet cross browser compatible). Voor IE zal je dan gebruik moeten maken van een ActiveX control (van bijv. Mircosoft) en voor FF zal je een XUL applicatie moeten maken. Een andere methode, en te implementeren zonder client side code, is dat je gebruik maakt van client side SSL (tegenwoordig TLS) authenticatie. Je moet dan op de client side (voor IE in je personal certificate store en voor FF in de browser certificate store) een certificaat installeren. Op server side kan je nu (evt. zelfs zonder gebruik te maken van een wachtwoord) heel goed bepalen wie er is ingelogd. Dit is natuurlijk niet zo mooi als het daadwerkelijk ondertekenen van een document met een digitale handtekening (zoals het 1e voorbeeld) aangezien alleen het transport is beveiligd en niet het document (de data) zelf. Het voordeel van de 2e aanpak is wel dat er op client side niet veel hoeft te gebeuren.

Je kan natuurlijk ook de keys op de server opslaan. De vraag is alleen dan wel of je daar echt veel mee opschiet aangezien dan de 'sterkte' van je beveiliging gelijk is aan je op dat moment gebruikte authenticatiemethode (en dat is dus in veel gevallen minder dan het gebruik van een digital signature)

Een (gratis) tooltje waarmee je encryped berichten kan maken, uploaden en verifieren (een digital ID aanvraag procedure is included) kan je vinden op:

https://www.izecom.com/download/installer/SetupIzeweb.exe

Een korte handleiding staat oa op:

http://www.izecom.com/download/EN/izemail_web.html

Disclaimer: Ik werk bij Izecom (waar dit tooltje te vinden is)

[ Voor 12% gewijzigd door martijn_brinkers op 04-09-2006 21:56 ]

[Zeezicht]

Volgens mij ben ik nog niet geheel duidelijk geweest. Het is voor mij niet van belang te weten wie is ingelogd (tenminste niet primair), want dat kan ik op meerdere manieren wel oplossen. Het gaat erom dat iemand bepaalde dingen selecteerd en dan als het ware de "koop" bevestigd met zijn handtekening. Met die handtekening weet ik zeker dat het die persoon is geweest en ook alleen die persoon kan die willekeurige selectie ondertekenen en niemand anders. Hoe die persoon tekent staat geheel vrij. Hoeft ook eventueel niet in IE of FF geintergreerd te zijn.

Ik zal die proggy's morgen eens bekeken, mss dat ik daar nog wat meer mee kan.

[Gomez12]

Moet het rechtsgeldig zijn ??? Indien nee, dan zou ik gewoon voor een password / hash gaan.

Want als ik jouw laatste opmerking zo lees dan vermoed ik dat jij pgp wil misbruiken tegenover een password. Terwijl het IMHO geen voordeel voor jou of voor je klant biedt tov een password alleen maar nadelen.
Als je bang bent dat mensen passworden gaan sharen, dat houd je net zogoed met private keys. Volgens mij biedt het geen voordeel alleen maar nadeel.

1 persoon mag maar dingen selecteren en bevestigen, dit is dus het persoon met het wachtwoord. Het wachtwoord kan wel uitgeleend worden aan iemand anders, maar een private key kan ook gewoon per email verzonden worden. Stel gewoon duidelijke voorwaarden op ( de persoon met het wachtwoord is beslissingsbevoegd en bij elke aankoop met dat wachtwoord wordt gefactureerd aan die persoon, wachtwoordsharing is verantwoordelijkheid klant )

En wees niet te zuinig met het uitgeven van wachtwoorden ( oorzaak nr 1 van wachtwoord sharing )

[Zeezicht]

Het moet inderdaad rechtsgeldig zijn. Daarom moet een bepaalde persoon of bedrijf iets kunnen ondertekenen en niet een anders. Zuinig doen met paswoorden is dus niet aan de orde. Elk persoon of bedrijf dat moet kunnen tekenen, krijgt zijn eigen keypair dan.

[MBV]

Ik zie nog steeds het nut niet in van zoiets ingewikkelds: het bied geen grote voordelen qua zekerheid, maar je introduceert wel wat moeilijkheden voor de gebruiker. Die zal daar niet op zitten te wachten, lijkt mij zo. Je blijft namelijk houden dat je klant een token op zijn pc opslaat, die (op zijn best) te lezen is met een gebruikersnaam en wachtwoord. Schiet dus niet echt op qua veiligheid.

De enige manier om het 'echt' veiliger te maken, is met een 'e-Dentifier' ofzo, zo'n kastje wat na het invoeren van een pincode een code omzet in een andere. Daarmee weet je zeker dat het iemand is die de pincode weet, zo'n kastje heeft waarin jouw private key zit, en de goede hash heeft ingevuld. Maar dat kost dus wel weer veel moeite met distributie van die kastjes enzo.

[Zeezicht]

Zo'n "kastje" kan toch ook gewoon een programma zijn? Die kan dan dmv een pincode zo code genereren...
Het moet niet moeilijk zijn, maar het mag niet zo zijn dat iemand anders bestelt op jouw kosten. Daarom moet er niet alleen ingelogd worden, maar ook ondertekent. Want anders kan ik zelf die bestelling van een klant faken. En dus ff voor een hoge omzet gaan ;-) Maar vooral ook dat het op die manier juridisch natuurlijk niet waterdicht is.

[martijn_brinkers]

Als je het echt volledig juridisch bindend wil laten zijn dan moet je het ondertekenen met een door de europese gemeenschap goedgekeurde digitale handtekening. Deze staat dan ook per definitie op een smartcard (het hierboven beschreven tooltje kan overigens ook overweg met zo'n goedgekeurde handtekening). Nadeel is natuurlijk dat zo'n goedgekeurde handtekening op smartcard niet goedkoop is. Je kan natuurlijk altijd onderling afspraken maken over de geldigheid van een software matig certificaat. In hoeverre zo'n afspraak 100% bindend is in het geval van een conflict is dan wat minder duidelijk (hoewel nog altijd sterker dan wanneer er gebruik zou worden gemaakt van een wachtwoord).

[MBV]

@Zeezicht: zo'n kastje kan geen programma zijn, omdat je de klant dan de private key moet geven. Het is dan eigenlijk een 'extra wachtwoord' geworden. Als je dat zou willen, moet je eens kijken naar de implementatie van SSH, dat kan ook op die manier werken.

Misschien eenvoudiger: na de overeenkomst een mailtje sturen met een confirmation link. Dat is vergelijkbaar met het rechtsgeldige alternatief: de fax. Fax sturen en ondertekend terug zien te krijgen, maar daar zit je waarschijnlijk niet op te wachten. Fax is daarentegen wel perfect juridisch bindend enzo.

[ Voor 37% gewijzigd door MBV op 06-09-2006 22:16 ]

[Gomez12]

@TS over welke order van grote van bestellingen praten we ??? Als het kleine bestellingen zijn ( gemiddeld 100 euro en lager ) dan zou ik zeggen volsta met of een fax ( rechtsgeldig ) of met een simpele naam/wachtwoord/email link combinatie.

Gaat het om grotere (terugkerende ) bestellingen dan kan je gaan denken over een idee als smartcard / readers uitgeven.Als een klant 5000 euro op jaarbasis doet dan is het best wel te overwegen om deze klant een smart card + reader cadeau te doen.
Alleen heb je met een smart card nog het probleem dat dit vaak op kantoren in een toegankelijke lade komt te liggen zodat iedereen erbij kan...

Het punt wat jij lijkt te vergeten is dat het heel moeilijk is om in een bedrijf 1 persoon aanwijsbaar te maken. Stel : jij verkoopt aan ons ons briefpapier, normaal gesproken loopt dit via de inkoopafdeling ( deze heeft dus een smartcard/private key /password ) maar nu is het vakantieperiode en de inkoopafdeling is op vakantie en ik heb briefpapier nodig. Wat gebeurt er nu in de meeste bedrijven : Oh, ik heb een smartcard nodig, laat ik eens kijken in de lades van de afdeling inkoop.
Op dit moment weet jij niet dat onze standaard inkoper het besteld heeft en het is ook niet de moeite waard om mij een aparte smartcard te geven, want ik bestel het misschien 1x per jaar uit nood.

Hoe wil jij hiermee omgaan???

[Equator]

Indien je een rechtsgeldig iets wilt maken dan kan je imo pgp weggooien. Natuurlijk kan je met pgp keurig berichten versleutelen, en misschien ook wle ondertekenen, maar of jij ook diegene bent die jij zegt dat je bent wordt nergens gevalideerd.

Wat dat betreft zal je toch naar PKI in de vorm van X509v3 certificaten moeten kijken. Een certificaat welke ondertekend is door een in nederland geaccepteerde certificeringsinstantie (CA) is IMO meer rechtsgeldig. Deze instantie heeft nl. de eis dat jij persoonlijk verschijnt om je te identificeren.

Binnen de overheid is er www.pkioverheid.nl welke een degelijke hierarchie heeft ingevoerd voor de overheid.

Natuurlijk is het wel zo dat, wanneer ik mijn smartcard laat slingeren met mijn pincode erop geschreven, elke rechtsgeldigheid in de prullenbak kan verdwijnen

Om terug te komen op de vraag van de TS:
Het is technisch natuurlijk mogelijk om serverside berichten te ondertekenen. Echter dat houdt in dat de server beschikking moet hebben over de private sleutel van die gebruiker. En dat is iets wat je niet wilt.
Dus de enige oplossing IMO zou zijn dat de gebruiker een bericht of wat dan ook in MS Word ondertekend met zijn private sleutel. Daarna dat word document post. Wanneer het wordt gewijzigd door iemand die niet de beschiking heeft over de private sleutel van de gebruiker wordt het bestand niet meer ondertekend en is de rechtsgeldigheid ervan verdwenen.
just my € 0,02

[ Voor 6% gewijzigd door Equator op 07-09-2006 07:43 ]