[C#] TCP transport protocol encryptie

[rikkert278]

Hallo allemaal!

Voor mijn profielwerkstuk werk ik aan een programma dat verbinding maakt met een server om zo data uit te wisselen. Ik gebruik hiervoor het TCP protocol en ik wil de verstuurde data graag versleutelen.

Nou heb ik in powerpoint het volgende encryptie schema gemaakt omtrent het uitwisselen van encryptie keys en dergelijke. Ik was benieuwd of ik iets over het hoofd heb gezien of dat ik een fout heb gemaakt waardoor mijn model niet meer secure zou zijn. Ik zou graag jullie input hierop willen hebben voordat ik begin met het bouwen en implementeren van deze manier. (Ik heb gezocht maar dit leek het beste forum voor mijn post, klopt het niet wees dan alsjeblieft zo vrij om de thread te verplaatsen naar het juiste sub-forum als je dat kunt).

Alle pakketjes worden omgezet naar een string voordat deze verzonden worden. Dit verzenden, het uit elkaar houden van pakketjes en het parsen van het ontvangen pakketje heb ik al werkende, ik moet alleen nog maar deze strings encrypten voordat deze verstuurd worden. Dit is het schema dat ik gemaakt had om versleutel keys uit te wisselen:



Graag ontvang ik wat tips en/of verbeteringen over mijn schema.

Bij voorbaat dank,

Schravendeel

[Mijzelf]

Waarom doe je de eventuele updates unencrypted? En hoe veilig moet het eigenlijk zijn? Ik zie hier geen enkele beveiliging tegen een 'valse server'.

[Voutloos]

Je hebt nu enkel encryptie tussen 2 partijen, met geen enkel bewijs voor de identiteit aan beide kanten. Leuk als iemand je netwerkverkeer afluistert, maar nutteloos zodra iemand ook maar 1 minuutje de moeite wilt nemen om man-in-the-middle te worden. Leesvoer: Certificates, Certificate Authority, en misschien wat meer zaken van TLS. Of leesvoer als het je enkel om het uitwisselen van keys gaat, zonder op identiteit en genoemde aanvallen te letten: Diffie-Hellman.

Het oranje deel duurt te lang, als je streeft naar minder unencrypted handelingen wil je in de 1e response al de pub key van de server krijgen. HWID van de client gaat derden niet aan, dus die wil je juist een requestje later sturen.

Tevens geen nonces of timestamps tegen replay attacks, en een aantal stappen zou extra encrypt kunnen worden. Bijv. de middelste groene pijl zou wellicht zowel met de public key vd server als met de reeds ontvangen AES encrypt kunnen (of zelfs moeten?) worden.

[Robin91]

Wanneer een public rsa key wordt verstuurd, zou een iets dat bericht kunnen onderscheppen.
Als deze node dan een eigen key genereerd en vervolgens naar het eindpunt stuurt (jou server), zullen alle gegevens gemakkelijk afgeluisterd kunnen worden.

Als je in de client een vaste (RSA) public key zet, welke de eas key verzend voor zowel het verzenden als ontvangen van data, is het al een stuk veiliger.

[ Voor 23% gewijzigd door Robin91 op 23-05-2012 23:14 ]

[azerty]

Een valse server (aka MITM) is mogelijk volgens mij, maar de re

Zie opmerking van Voutloos

[joppybt]

Schravendeel schreef op woensdag 23 mei 2012 @ 21:42:
Alle pakketjes worden omgezet naar een string voordat deze verzonden worden.

Wat moet ik me daar bij voorstellen? RSA encryptie en TCP communicatie werken uiteindelijke natuurlijk op bytes. Als jij pakketjes omzet naar string (base64?) wordt dan niet alleen maar de verstuurde data onnodig groter?

[H!GHGuY]

Waarom het wiel opnieuw uitvinden?
Gebruik SSL/TLS, bvb met OpenSSL; dat op zich is al een uitdaging...

[MLM]

Simpele manier:
1) Elke client heeft de public RSA (of andere) key in zijn installatie zitten
2) Bij opzetten veilige communicatie genereert de client een new RSA key, verzend de nieuwe public key naar de server, versleuteld met de public key van stap 1
3) Server is nu in bezit van de niewe public key van stap 2, en die kan je vanaf dan gebruiken (note: niemand anders kan stap 2 decrypten en communiceren met client, dus dit is direct ook authenticatie)

Als je geen keys kan meegeven in de installatie, moet je SSL oid gebruiken, maar dan heb je wel een (betaalde) key hebben van een echte CA om enige vveiligheid te garanderen

[joppybt]

Wat win je in stap 2 door een nieuw public/private sleutelpaar te introduceren?

Volgens mij is het alleen maar complexer dan een (goede) random AES-key maar niets veiliger.

[DiedX]

H!GHGuY schreef op donderdag 24 mei 2012 @ 13:03:
Waarom het wiel opnieuw uitvinden?
Gebruik SSL/TLS, bvb met OpenSSL; dat op zich is al een uitdaging...

Dit. Nu is het een proefwerkstuk, maar er zijn al zoveel partijen stukgelopen op encryptie...

Pak OpenSSL, zoek de juiste methode, fix het.

[Remus]

Aangezien hij C# gebruikt, hoeft hij helemaal niet met OpenSSL te gaan klooien. Gewoon de .NET features gebruiken die dit verzorgen:
MSDN: SslStream Class (System.Net.Security)

[Voutloos]

Misschien het werkstuk wel puur het nadenken hoe zoiets moeten werken, dus echt puur theorie ipv praktijk. Maar dan kom je gewoon op eerder genoemd leesvoer uit.

[MLM]

joppybt schreef op donderdag 24 mei 2012 @ 23:03:
Wat win je in stap 2 door een nieuw public/private sleutelpaar te introduceren?

Volgens mij is het alleen maar complexer dan een (goede) random AES-key maar niets veiliger.

Omdat je dan alle data van de server kan lezen, die bedoeld is voor andere clients