[java] encryptie (public/private keys)

[Verwijderd]

Iedereen is op de hoogte van de mogelijkheid tot decompilen van een java .class bestand.

Nu wil ik een java applet (op het grote net) via sockets laten communiceren met applicatie, draaiend op een server. Hoe kan ik dit veilig doen? Encriptie wordt dan lekker lastig, gezien bekent is hoe de encriptie tot stand komt (decompilatie van applet).

Op dit moment heb ik veel BZ&T in het gebruik van SSL zitten, maar nog niet voor elkaar gekregen!!

[Banpei]

Op dinsdag 23 april 2002 12:17 schreef pottieman het volgende:

Iedereen is op de hoogte van de mogelijkheid tot decompilen van een java .class bestand.

Nu wil ik een java applet (op het grote net) via sockets laten communiceren met applicatie, draaiend op een server. Hoe kan ik dit veilig doen? Encriptie wordt dan lekker lastig, gezien bekent is hoe de encriptie tot stand komt (decompilatie van applet).

Op dit moment heb ik veel BZ&T in het gebruik van SSL zitten, maar nog niet voor elkaar gekregen!!

Ooit gehoord van twee sleutelparen? Dan mag je best de encryptie methode weten, alleen duurt het dan wel een flinke tijd voordat je het gedecrypt hebt. Of 3 voudig encrypten?

Natuurlijk nooit de sleutels hardcoded zetten. Dat is het ergste wat je kan doen!

[Grum]

[mierenaanrandmode]
encryptie

[RickN]

Op dinsdag 23 april 2002 12:21 schreef Banpei het volgende:

[..]

Ooit gehoord van twee sleutelparen? Dan mag je best de encryptie methode weten, alleen duurt het dan wel een flinke tijd voordat je het gedecrypt hebt. Of 3 voudig encrypten?

Natuurlijk nooit de sleutels hardcoded zetten. Dat is het ergste wat je kan doen!

Je hoeft niet meervoudig te encrypten hoor.

De veiligheid van een encryptie methode wordt eigenlijk altijd bepaald in een situatie je ervan uitgaat dat de "vijand" full knowledge heeft, d.w.z. alles weet m.b.t. de encryptie methode behalve de gebruikte sleutel. Als je een bekende encryptie methode implementeerd maakt het dus niks uit dat mensen erachter kunnen komen welke methode je gebruikt, je zou bij wijze van spreken met grote koeien letter op in je applet kunnen vermelden welke methode je gebruikt.

[MDA]

Hoe duidelijker jij bent over de methode die je gebruikt hoe eerder mensen je op mogelijke fouten of verbeteringen zullen wijzen. De methode op zich moet goed zijn en niet er op gebaseerd zijn dat je de methode voldoende verborgen weet te houden, (dat lukt toch niet). Niet voor niets wordt van het encryptie programma PGP ook altijd de source code aangeboden, en denk niet dat het programma daar minder veilig door wordt.

[Verwijderd]

Maar stel hetvolgende:

De java applet maakt verbinding met de server. De server geeft het applet een sleutel waarmee ge-encrypt moet worden. De data(met name een naam en pincode) wordt met deze sleutel ge-encrypt, en naar de server verstuurd. De server decrypt dit weer met de verstuurde sleutel, en het lijkt een veilige actie geweest, alles klopte immers.

Nu heeft iemand over de (TCPIP) verbinding meegeluisterd. Hij heeft nu dus vanaf het eerste moment de sleutel gelezen, de sleutel is dus bij hem bekent. Vervolgens komt de ge-encrypte data (naam en wachtwoord) langs.

Het lijkt me dan een optel sommetje:
De sleutel is gezien, de gencrypte data is gezien, en
de java applet is bekent, dus de wijze van encrypting is
ook bekent.

Nu kan diegene die meegeluisterd heeft de ge-encrypte data decrypten, en zo de naam en password uitlezen.

Met deze gegevens kan diegene een nieuwe sessie starten, naam en wachtwoord invullen en zijn gang gaan!


Is dit te moeilijk gedacht? iemand kan dit toch doen?
En hoe kan ik dat voorkomen zonder SSL?

[Janoz]

Op dinsdag 23 april 2002 13:45 schreef pottieman het volgende:
Maar stel hetvolgende:

De java applet maakt verbinding met de server. De server geeft het applet een sleutel waarmee ge-encrypt moet worden. De data(met name een naam en pincode) wordt met deze sleutel ge-encrypt, en naar de server verstuurd. De server decrypt dit weer met de verstuurde sleutel, en het lijkt een veilige actie geweest, alles klopte immers.

Nu heeft iemand over de (TCPIP) verbinding meegeluisterd. Hij heeft nu dus vanaf het eerste moment de sleutel gelezen, de sleutel is dus bij hem bekent. Vervolgens komt de ge-encrypte data (naam en wachtwoord) langs.

Het lijkt me dan een optel sommetje:
De sleutel is gezien, de gencrypte data is gezien, en
de java applet is bekent, dus de wijze van encrypting is
ook bekent.

Nu kan diegene die meegeluisterd heeft de ge-encrypte data decrypten, en zo de naam en password uitlezen.

Je mist een essentieel punt van dit soort encryptie. Je hebt een sleutel om te encrypten en een sleutel om te decrypten. Deze zijn beiden verschillend en niet zomaar af te leiden uit elkaar. Als iemand de geencrypte data weet heeft ie niks aan de sleutel die gebruikt wordt bij het encrypten, maar alleen maar aan de sleutel die nodig is om te decrypten. Deze is echter nooit verstuurd en verblijft lekker veilig op de server.

[RickN]

Het uitwisselen van de sleutel moet je ook veilig doen. Key exchange heet dat, zoek daar maar eens op. Het komt er op neer dat meestal met een public key algoritme een sleutel voor een private key algoritme wordt uitgewisseld. Dit is een bekende methode en toch veilig als iemand de preciese methode kent.

edit:
Het uitwisselen van de sleutel met een public key algoritme is veilig om de reden die Janoz hierboven uitlegt.

[Banpei]

Over het algemeen geldt ook de stelregel dat de tijd waarin jouw encryptie methode gekraakt kan worden (brute force bijvoorbeeld) je door de helft moet nemen en die tijd als interval moet nemen om de sleutels te vervangen met nieuwe.

[MDA]

Janoz heeft het essentiele punt al aangestipt maar ik zal het nog even proberen te verduidelijken. De server stuurt zijn public key naar het applet, met deze public key versleutelt het applet de data en stuurt deze op. Dit is een 1 weg versleuteling, data die is versleutelt met de public key kan alleen worden ontsleutelt met de private key van de server. Deze staat op een velige plek op de serever en blijft daar ook. Wil je ook dat de data die van de serever naar het applet gaat wordt versleuteld dan kun je de hele truuk ook andersom uithalen. Omdat het misschien veel werk is om ook het applet een publickey pair te laten genereren kun je misschien een random key aanmaken en deze versleuteld naar de server sturen, vervolgens laat je de server deze key gebruiken om met AES, 3DES, de data weer versleuteld naar het applet te sturen. Als je dit allenmaal netjes weet uit te voeren kun je de zaken redelijk dicht timmeren. Alleen blijf je kans houden op een zogenaamde "man in the middle attack" maar de persoon die zo goed is dat hij dit kan zal eerder proberen de server te hacken, dat is namelijk minder werk. Veel Succes!

[blackbit]

Je kunt ook de encryptiemethode meesturen bij het begin van de communicatie; zo kun je verschillende classes maken voor verschillende encryptie/decryptie methodes, en wanneer de sessie start, stuur je de class over die verantwoordelijk is voor het decrypten. Zo kun je dan elke keer een 'random' encryptiealgoritme aanmaken op de server en meesturen. Dit heeft het voordeel dat men nooit weet welke encryptie de volgende keer zal gebruikt worden.

-> Je kunt op die manier ook hard coded een tijdslimiet in de module steken. Op die manier werkt ie zeker maar een keer! (Uiteraard eerst de tijd op de client opvragen en doorsturen naar de server).

[Verwijderd]

Op dinsdag 23 april 2002 13:50 schreef Janoz het volgende:

[..]

Je mist een essentieel punt van dit soort encryptie. Je hebt een sleutel om te encrypten en een sleutel om te decrypten. Deze zijn beiden verschillend en niet zomaar af te leiden uit elkaar. Als iemand de geencrypte data weet heeft ie niks aan de sleutel die gebruikt wordt bij het encrypten, maar alleen maar aan de sleutel die nodig is om te decrypten. Deze is echter nooit verstuurd en verblijft lekker veilig op de server.

Dat is duidelijk...
Maar hetvolgende:
- Server stuurt AB als sleutel naar client.
- Het applet heeft als encryptie pin + sleutel. Gebruiker
voert CD in, applet verstuurd dan ABCD naar server.
- Iemand luistert en ziet dus eerst AB en daarna ABCD
langskomen. De luisteraar weet de encryptiemethode en
weet dus de pincode.

De volgende sessie kan hij als gebruiker dan toch inloggen?

[RickN]

Euh, encryptie is niet de sleutel aan het bericht vastplakken en dan opsturen...

De sleutel wordt gebruikt om het bericht op zo'n manier door elkaar te husselen en dergelijke dat het originele bericht niet meer te achter halen is. Dus als AB de sleutel is en CD het bericht dan is het versleutelde bericht meer iets van GWUX oid. Misschien moet je eerst nog wat meer over encryptie gaan lezen voordat je een website gaat beveiligen. No offence hoor, maar dat lijkt me wel verstandiger...

edit:
Of interpreteer ik je voorbeeld verkeerd???

[Verwijderd]

Op dinsdag 23 april 2002 14:18 schreef RickN het volgende:
Euh, encryptie is niet de sleutel aan het bericht vastplakken en dan opsturen...

De sleutel wordt gebruikt om het bericht op zo'n manier door elkaar te husselen en dergelijke dat het originele bericht niet meer te achter halen is. Dus als AB de sleutel is en CD het bericht dan is het versleutelde bericht meer iets van GWUX oid. Misschien moet je eerst nog wat meer over encryptie gaan lezen voordat je een website gaat beveiligen. No offence hoor, maar dat lijkt me wel verstandiger...

Is dat zo?

...het is dan misschien niet zo simpel als optellen, maar het is wel met behulp van een algoritme. Wat maakt het nu uit of je een simpele optelling gebruikt of een moeilijker algoritme.

Mijn punt is dat wanneer je meeluisterd op het moment van versturen van de sleutel, en het versturen van het ge-encrypte gedeelte, dan kun je samen met de encryptiemethode de ingevoerde gegevens achterhalen.

Eerderop is de tip gegeven op Internet Key Exchange te onderzoeken, hier ben ik nu mee bezig.


...Ik hoop dit op te lossen zonder gebruik te maken van SSL...

[JapJap]

pottieman:

Mijn punt is dat wanneer je meeluisterd op het moment van versturen van de sleutel, en het versturen van het ge-encrypte gedeelte, dan kun je samen met de encryptiemethode de ingevoerde gegevens achterhalen.

Niet dus als je asymmetrische encryptie gebruikt, wat al tig keer verteld is hierboven

[Birk]

Op dinsdag 23 april 2002 14:26 schreef pottieman het volgende:
Is dat zo?

Hier is een handig linkje : Encryptie

Is handig om die door te lezen, dit is de basis van hoe dit werkt.

[Banpei]

Op dinsdag 23 april 2002 14:26 schreef pottieman het volgende:

[..]

Is dat zo?

Dan kunnen ze bij Brinks waarde transport net zo goed ook de sleutel aan de buitenkant van de auto plakken... Lijkt me net zo veilig als gewoon de deur helemaal openzetten...

...het is dan misschien niet zo simpel als optellen, maar het is wel met behulp van een algoritme. Wat maakt het nu uit of je een simpele optelling gebruikt of een moeilijker algoritme.

Mijn punt is dat wanneer je meeluisterd op het moment van versturen van de sleutel, en het versturen van het ge-encrypte gedeelte, dan kun je samen met de encryptiemethode de ingevoerde gegevens achterhalen.

Eerderop is de tip gegeven op Internet Key Exchange te onderzoeken, hier ben ik nu mee bezig.

De IKE is een prima manier om sleutels veilig te transporteren.

Korte samenvatting van IKE: Server stuurt de public key (dus niet de decryption key, maar de encryption key) naar applet. Applet heeft zelf ook public en private key gegenereerd. stuurt dmv de server public key zijn eigen public key. Server heeft nu de public key van Applet.

Belangrijk punt wat je moet zien is dat de encrypted messages die gestuurd worden dan alleen door de private key geencrypt kunnen worden. NIEMAND behalve de Applet heeft de private key van Applet. NIEMAND behalve de server heeft de private key van de Server. Dan mag iedereen best beide public keys hebben, maar ze hebben er dus geen ruk aan. Je kan geen messages encrypten en niet decrypten want daarvoor heb je een private en public key nodig.

Op deze manier weet de server dat het dus alleen van Applet kan komen. Hiermee verstuur je dus je session keys over en weer. Niemand kan het lezen en is de key veilig over gekomen. De session encryptie is over het algemeen een eenvoudigere encryptie methode (des bijvoorbeeld) en daarmee ga je de data encrypten. DES kraken is relatief eenvoudig, dus om de zoveel tijd verstuur nieuwe sleutels.

Oftewel: dit is precies hoe je met IPSec van Cisco een VPN opzet...

[Birk]

Op dinsdag 23 april 2002 15:42 schreef Banpei het volgende:
Oftewel: dit is precies hoe je met IPSec van Cisco een VPN opzet...

Precies dit is exact de IPSec methode, maar om die compleet te begrijpen moet eerst een stukje Public/Private Encryptie begrepen worden omdat deze methode daarop gebouwd is...