Cryptography

[MLM]

Ik ben geen expert op het gebied van cryptography, dus ik hoop dat iemand even mijn veronderstelling kan bevestigen. Ik heb eea doorgenomen van wikipedia, en begrijp de basis volgens mij wel.

Stel: Er zijn 2 computers, een server (S) en een client (C). De bedoeling is om een beveiligde verbinding op te zetten tussen deze twee. Hiervoor gebruik ik een assymetrisch systeem (public key systeem). We gaan er van uit dat C in bezit is van de public key van S.
1) C genereert een keypair.
2) C versleuteld zijn public key met de public key van S, en verstuurd dit bericht aan S.
3) S ontsleuteld het bericht, en haalt hieruit de public key van C.
4) Zowel C en S zijn in bezit van elkanders public key, dus door vanaf nu altijd elkaars public key te gebruiken om al het verkeer te versleutelen, maakt dit veilig.

Klopt het dat er geen praktische aanval is op dit systeem?
(ik realiseer me dat dit voor sommigen vast een simpele vraag is, in dat geval is een simpele ja voldoende)

[Nvidiot]

Twee opmerkingen:
1. Voor bulk-data gebruik je in principe een symmetrisch algoritme zoals AES. Je kunt een asymetrisch systeem gebruiken om de key voor het symmetrische algoritme uit te wisselen. Asymetrische systemen zijn nogal traag, dus niet handig voor bulk-data.
2. Het probleem bij dit systeem is dat C niet zeker kan weten dat de public key van S ook daadwerkelijk van S is en niet van een kwaadwillende gebruiker. Om dat op te lossen kun je certificaten gebruiken.

[susscorfa]

Als je dingen veilig wil doen is het dan niet vele malen beter om een getest en bekend systeem te gebruiken zoals openssh. eigen implementaties worden wss veel minder uitgebreid getest.

[Jaap-Jan]

Nvidiot schreef op zaterdag 23 augustus 2008 @ 16:37:
Twee opmerkingen:

1. Voor bulk-data gebruik je in principe een symmetrisch algoritme zoals AES. Je kunt een asymetrisch systeem gebruiken om de key voor het symmetrische algoritme uit te wisselen. Asymetrische systemen zijn nogal traag, dus niet handig voor bulk-data.

Anders geformuleerd: S versleutelt een sessiesleutel met zijn private key, stuurt die naar C en vervolgens versleutelt S alle berichten met die sessiesleutel. Dat is ook de manier waarop SSL werkt.

2. Het probleem bij dit systeem is dat C niet zeker kan weten dat de public key van S ook daadwerkelijk van S is en niet van een kwaadwillende gebruiker. Om dat op te lossen kun je certificaten gebruiken.

Hoezo? Als C op een veilige manier de public key van S heeft ontvangen, dan is dat toch geen probleem? Zolang de private key van S niet is gecompromitteerd, kan een kwaadwillende gebruiker ook niets met die versleutelde tekst.

[begintmeta]

Het gaat in principe zo:

C en S maken allebei een sleutelpaar (een private en een public key).
De public key kan in principe vrij beschikbaar worden gesteld, aangezien het niet mogelijk is hiermee transacties te ondertekenen of te ontsleutelen.
C&S moeten natuurlijk wel zeker weten dat ze de juiste public keys hebben, hiervoor is dus een manier nodig om zeker te weten dat de ontvangen sleutel de juiste is. (bijvoorbeeld (1 van beide) persoonlijk overhandigen, stappen 2+3 kunnen dan overbodig zijn als je elkaar toch ontmoet)

Waarom kies je eigenlijk niet voor een symmetrische versleuteling? Wat wil je doen?

leuk linkje: cryptool

[ Voor 5% gewijzigd door begintmeta op 23-08-2008 16:49 ]

[MLM]

dank je beide.
het gaat in dit geval om beveiliging van een UDP verbinding, ie, niet alle pakketten zullen worden ontvangen. Daar is (zover ik weet), nog geen bestaande implementatie voor.

Ik wil inderdaad mijn initiele systeem gebruiken om een block-cipher key uit te wisselen voor de "echte" data. Nadeel daarvan is dat ik daarna gelijk vast zit aan ECB of CTR mode of operation (omdat het best mogelijk is dat vorige berichten niet ontvangen zijn), de rest is exclusief voor streaming modes (zie Wikipedia: Block cipher modes of operation)

[ Voor 6% gewijzigd door MLM op 23-08-2008 16:51 ]

[begintmeta]

Is het erg dat niet alle paketten worden ontvangen? Heb je beperkte bandbreedte? Is een self-synchronizing stream cipher geschikt voor je toepassing?

[ Voor 37% gewijzigd door begintmeta op 23-08-2008 17:13 ]

[MLM]

@begintmeta: ik kies niet voor symmetrisch omdat het een multi-user systeem is. Dan kan ik niet kiezen voor 1 symmetrische key, immers, dan kunnen de andere users de informatie van een andere user afluisteren, omdat ze zelf de decryption key hebben.
En een stream cipher is geen optie, omdat de data inherent geen stream is, maar losse pakketjes zonder volgorde (UDP). Die losse pakketjes worden dan als [checksum + originele data] met de sessionkey versleuteld. De ontvanger van dat pakketje kan dan met de session key de data ontsleutelen en verifieren dat er niet mee geknoeid is door de checksum te controleren.
(En nee, ik gebruik hier natuurlijk niet de checksum van UDP voor, aangezien je die sowieso kan forgen als je met het pakketje knoeit)

[curry684]

Wat voor reden heb je om UDP te gebruiken uberhaupt in deze moderne breedbandwereld?

Ik kan me weinig toepassingen voorstellen waarbij UDP merkbare voordelen boven TCP heeft en zware encryptie gewenst is.

[begintmeta]

Het lijkt me toch niet zo lastig om voor elke gebruiker een andere key te maken(@hieronder: OK, wel lastig als je met veel gebruikers 'zit'), wil je het veilig maken moet je toch een veilige overdracht van S naar C kunnen opzetten.

Kun je trouwenseigenlijk niets met IPsec?

[ Voor 15% gewijzigd door begintmeta op 23-08-2008 17:42 ]

[MLM]

Het betreft een game-omgeving, waarbij first-person elementen komen kijken. Daarvoor stel ik wel een eis aan reactiesnelheid. Tevens is het niet belangrijk bij alle data (gedeeltelijk) dat alle verzonden data daadwerkelijk aankomt. Een gedeelte account management waarbij al dan niet virtueel geld bij komt kijken vereist beveiliging.

Ik overweeg om daarvoor een UDP library te schrijven, waar een optionele reliability en/of beveiligings layer zit. Op het moment is dit voornamelijk een idee in mijn hoofd, en ik overweeg realisatie. Voorlopig leek me dit 1) intressant 2) mooie C++ ervaring 3) de optimale oplossing. Tuurlijk, er zijn alternatieven, bijv: TCP /w streamcipher voor het ene opzetten, en daarnaast een UDP voor alle FPS elementen opzetten.

@begintmeta: IPSec zit volgens mij in de verkeerde OSI layer. Ik wil het over internet laten werken

[ Voor 6% gewijzigd door MLM op 23-08-2008 17:43 ]

[begintmeta]

MLM schreef op zaterdag 23 augustus 2008 @ 17:39:
@begintmeta: IPSec zit volgens mij in de verkeerde OSI layer. Ik wil het over internet laten werken

Klopt, maar het is wel een oplossing voor het probleem: je wilt een optionele betrouwbaarheids-/beveiligingslaag. Je kunt mensen dan bijvoorbeeld de mogelijkheid geven een IPsec-verbinding te gebruiken (Het kan ook allemaal heel laagdrempelig opgezet, je wilt toch de software zelf maken, dan kun je het zo maken als je wilt.) linkje

[ Voor 10% gewijzigd door begintmeta op 23-08-2008 19:37 ]

[Rukapul]

begintmeta schreef op zaterdag 23 augustus 2008 @ 19:26:
[...]

Klopt, maar het is wel een oplossing voor het probleem: je wilt een optionele betrouwbaarheids-/beveiligingslaag. Je kunt mensen dan bijvoorbeeld de mogelijkheid geven een IPsec-verbinding te gebruiken (Het kan ook allemaal heel laagdrempelig opgezet, je wilt toch de software zelf maken, dan kun je het zo maken als je wilt.) linkje

Onzin. IPsec heeft 2 problemen waardoor het volstrekt niet laagdrempelig is voor applicatiespecifieke (non-VPN) toepassingen:
• integratie met applicaties is lastig (vergelijk TLS: kwestie van een library call voor een secure socket)
• allerlei artefacten van het moderne Internet zoals NAT routers zorgen voor problemen (vergelijk TLS: als je verbindingen kan opzetten dan werkt TLS ook)

TS moet gewoon TCP+TLS gebruiken in de basis. Indien er echt een noodzaak is voor UDP dan eerst bekijken of dat beveiliging vereist, zo ja een library van het net pakken (ze zijn er wel). Onder geen beding reliability aan UDP toevoegen aangezien je dan een home made TCP implementatie aan het maken bent.

[ Voor 4% gewijzigd door Rukapul op 23-08-2008 19:56 ]

[soulrider]

en zou je dat gebruikers gedeelte niet perfect over tcp kunnen regelen, terwijl het game-aspect over udp gaat ?

er zijn verschillende games vindbaar die beide protocollen gebruiken al dan niet over dezelfde poort.

(tcp om met stats-server te spreken, udp om met mee-/tegenstanders te communiceren)

[Gomez12]

Sowieso lijkt UDP met cryptographie mij absoluut niet de ideale oplossing. Alles wat met cryptographie te maken heeft moet je gewoon over TCP gooien.
Bij cryptographie is het van redelijk belang dat je alle bitjes hebt. Mis je 1 bitje kan je je hele pakket gelijk niet meer decrypten.

Uberhaupt is udp uitermate ongeschikt voor reliable data. Als een speler opeens een stuurt dat hij 500 goud gekregen heeft, heeft hij dan gecheat of heeft de server gewoon een x aantal pakketjes gemist waardoor de server het niet opmerkte?

[begintmeta]

Rukapul schreef op zaterdag 23 augustus 2008 @ 19:55:
[...]

Onzin. IPsec heeft 2 problemen waardoor het volstrekt niet laagdrempelig is voor applicatiespecifieke (non-VPN) toepassingen:
• integratie met applicaties is lastig (vergelijk TLS: kwestie van een library call voor een secure socket)
• allerlei artefacten van het moderne Internet zoals NAT routers zorgen voor problemen (vergelijk TLS: als je verbindingen kan opzetten dan werkt TLS ook)
...

Ik kon me een soort Voice-VPN-achtig scenario voorstellen, het verpakken van de IPsec in UDP maar ik ben (dat mag wel duidelijk zijn) niet bepaald een low-level networkadmin...

[MLM]

Het lijkt me makkelijker om zowel een TCP als UDP verbinding op te zetten voor het moment. Mocht dat om 1 of andere reden niet voldoen later, zien we dan wel weer Premature optimization etc

Anyway, bedankt voor alle feedback, ben weer wat geinformeerder over diverse typen cryptography en hun voor/nadelen

[farlane]

Gomez12 schreef op zaterdag 23 augustus 2008 @ 20:49:
Alles wat met cryptographie te maken heeft moet je gewoon over TCP gooien.

Deze twee staan volgens mij volledig los van elkaar, ik snap niet waar die uitspraak op gebaseerd is ...

[Gomez12]

farlane schreef op zondag 24 augustus 2008 @ 01:14:
[...]


Deze twee staan volgens mij volledig los van elkaar, ik snap niet waar die uitspraak op gebaseerd is ...

UDP is een niet gegarandeerd protocol, voor het ontsleutelen van 1 pakketje is het wel makkelijk als je het hele pakketje hebt. UDP biedt hier geen garanties voor.
Dit is wel allemaal na te bouwen met checksums etc die je in UDP kan gaan zetten, maar in principe ben je dan een poor man's TCP/IP aan het namaken.

[Rukapul]

Gomez12 schreef op zondag 24 augustus 2008 @ 09:26:
[...]

UDP is een niet gegarandeerd protocol, voor het ontsleutelen van 1 pakketje is het wel makkelijk als je het hele pakketje hebt.

Daarom encrypt je in dergelijke gevallen per packet. Probleem opgelost. Encryptie van content stromen zoals RTP over UDP of zoals MPEG transport stromen over satelliet, kabel of ether werken niet anders.

[MLM]

UDP garandeerd geen aflevering, wel dat ALS je een datagram ontvangt, het het hele datagram is. Dus je weet dat je altijd met een heel pakketje zit te werken

Je verward met TCP, die, indien nodig, pakketjes kan opsplitsen of samenvoegen. Op zich maakt dat voor TCP natuurlijk niet uit omdat het een stream is.

[EdwinG]

Jaap-Jan schreef op zaterdag 23 augustus 2008 @ 16:44:
[...]

Anders geformuleerd: S versleutelt een sessiesleutel met zijn private key, stuurt die naar C en vervolgens versleutelt S alle berichten met die sessiesleutel. Dat is ook de manier waarop SSL werkt.

Zodat iedereen die het bericht met de sleutel er in onderschept deze met de publieke sleutel van S weet te ontcijferen? Lijkt me niet echt een veilige oplossing.

Het is logischer om de sleutel door C te laten bepalen, te versleuten met de publieke sleutel van S en daarna op te sturen. De enige manier om het bericht te ontcijferen is dan met de private key van S, en die is alleen bij S bekend.

[Jaap-Jan]

EdwinG schreef op zondag 24 augustus 2008 @ 13:02:
[...]


Zodat iedereen die het bericht met de sleutel er in onderschept deze met de publieke sleutel van S weet te ontcijferen? Lijkt me niet echt een veilige oplossing.

Het is logischer om de sleutel door C te laten bepalen, te versleuten met de publieke sleutel van S en daarna op te sturen. De enige manier om het bericht te ontcijferen is dan met de private key van S, en die is alleen bij S bekend.

Het was inderdaad net andersom, stom van me.

[begintmeta]

Gomez12 schreef op zondag 24 augustus 2008 @ 09:26:
...
Dit is wel allemaal na te bouwen met checksums etc die je in UDP kan gaan zetten, maar in principe ben je dan een poor man's TCP/IP aan het namaken.

Of een soort IPsec in transportmodus (of heb ik dat verkeerd begrepen )

[Verwijderd]

Het probleem met niet alle data ontvangen is, dat Cipher Block Chaining (CBC) niet mogelijk is; je zult iets met Electronic Code Book (ECB) moeten doen. Minder veilig, maar wel de makkelijkste manier. En als diverse andere partijen (zoals content providers) er al mee werken, is het blijkbaar een werkbare oplossing.

Encryptie per pakket is een optie. Asymetrische crypto is dan misschien zo gek nog niet. Hoewel het wel extra processorkracht kost, en dat kan met een game best oplopen.

[BCC]

Kun je niet UDP over HTTPS sturen? Of zeg ik nou hele rare dingen?

[ Voor 32% gewijzigd door BCC op 25-08-2008 15:34 ]

[Herko_ter_Horst]

Je zegt hele rare dingen

[roy-t]

BCC schreef op maandag 25 augustus 2008 @ 15:33:
Kun je niet UDP over HTTPS sturen? Of zeg ik nou hele rare dingen?

Je zegt niets raars want UPD is slechts het mechanisme wat de pakketten verspreid en HTTPS is een protocol een paar lagen daar boven op, doordat alle netwerklagen een zelfde interface hebben naar boven en beneden kun je dus vrij kiezen. Het zou dus mogenlijk moeten zijn, maar of het handig is hiervoor.

[Herko_ter_Horst]

Pardon? UDP zou hooguit onder HTTPS kunnen zitten. Je kan geen UDP over HTTPS sturen.

[ Voor 17% gewijzigd door Herko_ter_Horst op 25-08-2008 15:47 ]

[Voutloos]

roy-t, HTTPS != drop in replacement voor HTTP in de applicatie laag. Sterker nog, de veranderingen zitten juist niet in de app. laag.

[Soultaker]

Bedoel je nu SSL of wat? Het nadeel daarvan is dat je toch over TCP moet.

Overigens denk ik dat begintmeta een goed punt heeft: de TS wil eigenlijk gewoon IPsec in transport mode, maar dan waarschijnlijk zonder de officiële protocollen te gebruiken. Nietemin is het waarschijnlijk een goed idee om de ESP en AH headers van IPsec na te apen, omdat er over een aantal zaken bij IPsec al goed nagedacht is, en je zo niet het wiel opnieuw hoeft uit te vinden.

[ Voor 5% gewijzigd door Soultaker op 25-08-2008 16:02 ]

[curry684]

roy-t schreef op maandag 25 augustus 2008 @ 15:39:
[...]


Je zegt niets raars want UPD is slechts het mechanisme wat de pakketten verspreid en HTTPS is een protocol een paar lagen daar boven op, doordat alle netwerklagen een zelfde interface hebben naar boven en beneden kun je dus vrij kiezen. Het zou dus mogenlijk moeten zijn, maar of het handig is hiervoor.

Dat layers in beginsel generiek vervangbaar zijn betekent nog niet dat je ze *om kunt keren*. Wat je voorstelt is hetzelfde als ethernetframes over IP routen: hoewel niet onmogelijk wel nutteloos.

[MSalters]

curry684 heeft geen ervaring met netwerken aan elkaar knopen? Het kan wel degelijk nut hebben als je twee ethernet netwerken aan elkaar wil knopen via Internet. Aangezien de gemiddelde ISP jouw ethernet niet gaat routen zul je toch echt Ethernet over IP moeten doen. Om dezeflde reden kun je dus ook UDP over HTTP doen.

Staat los van het feit dat BCC inderdaad hele rare dingen zegt.

[BCC]

MSalters schreef op maandag 25 augustus 2008 @ 16:38:
Staat los van het feit dat BCC inderdaad hele rare dingen zegt.

Daar was ik al bang voor

[begintmeta]

Misschien ook wel leuk linkje als suggestie voor de TS.