Autenticatie, welk type encryptie gebruiken

[gangkill13]

Ik ben op zoek naar kennis over encryptie/authenticate

Een project waarbij ik het volgende wil bereiken.
De client stuurt een bericht (tcp over lan) naar de server om een bepaalde actie uit te voeren. Het is belangrijk dat alleen ik die actie kan uitvoeren. Dus moet de server kunnen controleren dat het bericht van mij afkomstig is en niet van iemand anders.

Vergelijkbaar met een draadloze autosleutel -> de auto moet weten of het bericht dat de sleutel verstuurd afkomstig is van één van de vertrouwde sleutels.

Op het internet gekeken naar informatie hoe ik dat kan bereiken.

Één van de dingen die ik voor ogen heb is het volgende:

Zowel client als server zijn in het bezit van een unieke sleutel die gebruikt wordt voor encryptie/decryptie.

1. De client stuurt een request naar de server voor een random code.
2. De server genereert een random code en versleuteld deze met SHA-256 AES (ECB mode)
3. De client ontvangt de versleutelde code en ontsleuteld deze.
4. De client versleuteld (code + bericht) en verstuurd dit naar de server
5. De server ontleuteld het bericht, kijkt of de code overeenkomt met degene die eerder naar de client is gestuurd, zo ja dan kan er iets met het bericht worden gedaan.

Hiermee kan de server controleren of het bericht van mij afkomstig is (ik en de server zin immers de enigen die de berichten kunnen versleutelen/ontsleutelen) en zijn replay-attacks niet mogelijk.

Een ander idee dat ik had is het gebruik van AES in CTR mode waarbij de counters van de clients en de server gelijk zijn.

Maar omdat ik hier dus geen expert in ben ben ik benieuwd naar jullie meningen/suggesties
Als er betere alternatieven zijn dan hoor ik het graag!

[HMS]

Waarom gebruik je niet de mogelijkheden die SSL al heeft? Geef elke client zijn eigen certificaat en verifieer deze aan de server kant.

[ViNyL]

Misschien valt hier inspiratie uit te halen?

https://crackstation.net/hashing-security.htm
https://github.com/whispersystems/

[ Voor 16% gewijzigd door ViNyL op 19-05-2016 16:56 ]

[Rannasha]

gangkill13 schreef op donderdag 19 mei 2016 @ 16:48:
• De server genereert een random code en versleuteld deze met SHA-256 (ECB mode)
• De client ontvangt de versleutelde code en ontsleuteld deze.

SHA-256 is een hashing algoritme, geen versleutelings algoritme. Ontsleutelen van een SHA-256 hash zit er dus niet in (en dat is by design).

Er is al opgemerkt dat je kunt kijken naar bestaande technieken zoals SSL. Dat is vaak de veiligste weg, gebruikmaken van algemeen gebruikte methodes in plaats van het wiel zelf opnieuw uit te vinden.

Als je zelf iets in elkaar wil knutselen, lees dan eens wat over "Message Authentication Codes" (MAC) (Wikipedia: Message authentication code) of digitale handtekeningen (Wikipedia: Digital signature), twee methodes om te verifieren dat de verzender is wie hij zegt dat hij is en dat de boodschap niet gedurende het proces is aangepast door een derde partij.

Een dergelijk systeem bestaat uit sleutels die uitgewisseld worden tussen client en server (dit uitwisselen dient eenmalig te gebeuren, het liefst via een ander kanaal dan waar de communicatie later over gaat lopen). Met de sleutel kan een bericht ondertekend worden en de persoon aan de andere kant verifieren dat de handtekening en het bericht horen bij de sleutel die hij heeft. Het verschil tussen MAC en digitale handtekeningen zit in het feit dat MACs symmetrische algoritmes gebruiken (beide partijen hebben dezelfde sleutel en kunnen elkaar boodschappen sturen op deze manier) en digitale handtekeningen gebruiken asymmetrische algoritmes (een partij kan ondertekenen, de ander kan alleen verifieren).

[gangkill13]

Bij SSLwordt toch het certificaat van de server gecheckt en niet andersom?

Ik bedoelde ook AES i.p.v. SHA. '

MAC had ik ook naar gekeken of eigenlijk HMAC. Ik denk dat HMAC voor deze toepassing het beste is.

[Ventieldopje]

Het lijkt mij veel makkelijker om SSL TLS te implementeren dan om te gaan knutselen met HMAC (MAC is kwetsbaar voor een length attack).

SSL (of eigenlijk TLS) is lang niet alleen maar het valideren van een server certificaat zoals bij HTTPS gebeurd. Je kunt namelijk ook op de server vereisen dat de client een key/cert heeft die overeenkomt met het root certificaat dat je opgeeft op de server.

Meer over hoe dat proces gaat kun je hier vinden: https://gist.github.com/mtigas/952344. De implementatie hangt af van je gebruikte taal maar als je gewoon OpenSSL (of een van de forks) gebruikt zal er niks aan de hand zijn.

[BramV]

Makkie met nodejs

https://coolaj86.com/arti...th-webcrypto-and-node-js/

[johnkeates]

TLS, SSH, Kerberos, RADUIS... gebruik iets wat er al is en wat bewezen is en onderhouden wordt, ga niet zelf iets knutselen.

[Woy]

gangkill13 schreef op donderdag 19 mei 2016 @ 17:37:
Bij SSLwordt toch het certificaat van de server gecheckt en niet andersom?

Bij TLS heb je ook zoiets als Client Certificates, dus dat kan gewoon twee kanten op zijn.

[wording]

In theorie mogelijk als volgt (maar doe dit niet):

Als de server en client een gedeeld secret X hebben:

1. Server stuurt random string Y naar client
2. Client stuurt hash(Y + X) naar server (eventueel + Z, een instructie die tevens ongehasht meegestuurd wordt)
3. Server vergelijkt ontvangen hash met zelf berekende hash.

In de praktijk gewoon een bestaand protocol gebruiken; bovenstaande is ongetwijfeld voor allerlei aanvallen vatbaar, zoals bij sommige hash-functies de bovengenoemde Wikipedia: Length extension attack.

[ Voor 27% gewijzigd door wording op 20-05-2016 17:02 ]

[gangkill13]

Oké, een bestaand protocol ik ga ermee verder. Als ik verder ben zal ik laten weten hoe het loopt!

[Cartman!]

In principe nooit ECB mode gebruiken ook voor encryptie: https://blog.filippo.io/the-ecb-penguin/