Tel alle letters n verder.
Dit is heel makkelijk te kraken, want je weet dat de ‘e’ statistisch het vaakste voorkomt, dus de letter, die het vaakste voorkomt, is waarschijnlijk een ‘e’. Neem bijvoorbeeld ‘Igjgko’. De ‘g’ komt het vaakst voor, dus is dat waarschijnlijk de ‘e’. De ‘g’ is 2 posities verder dan de ‘e’, dus de geheime n = 2. Met n=2 wordt het alfabet e=g, g=i, h=j, i=k, m=o. Het woord wordt dan ‘Geheim’.
Om te coderen en decoderen heb je een ‘shared secret’ of ‘shared key’, n, nodig.
34 = 3 * 3 * 3 * 3 = 81
Terugrekenen heet worteltrekken (of ontbinden in factoren) en ‘de 4e machts wortel van 81’ is dus 3.
Worteltrekken is erg veel werk in vergelijking met machtsverheffen.
Bij encryptie zijn de getallen bijvoorbeeld 300 cijfers lang (1024 bits). 1 miljard is 9 cijfers, dus we hebben het hier over 33 miljards achter elkaar. Dat is dus GROOT, zo groot:
999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
Hierdoor is worteltrekken in praktijk vrijwel onmogelijk.
Omdat ik de presentatie een beetje overzichtelijk moet houden, zal ik machtsverheffen door vermenigvuldigen vervangen en worteltrekken door delen, maar bedenk dat de getallen reusachtig zijn en dat delen (d.i. worteltrekken) in praktijk te moeilijk en te veel werk is.
Stel jij hebt een bericht (message) m en die wil je naar mij sturen.
Zet hiervoor m om naar een getal, bijvoorbeeld door de ASCII(unicode) codes te nemen. m is nu een getal.
c = m * k
c is de gecodeerde tekst (ciphertext) en k is de sleutel (key) waarmee dit gedaan is.
De ciphertext c is de tekst, die naar mij gestuurd wordt.
VRAAG: Hoe krijg ik daar nu het originele bericht m weer uit terug?
Twee opties:
Natuurlijk had ik p niet toevallig. p is de private key, die hoort bij de public key k en ze zijn samen gegenereerd. Het is niet mogelijk (net zo moeilijk als delen is) om de private key uit de public key af te leiden. Ook is er maar 1 private key bij elke public key (en omgekeerd). [Dit komt doordat ze zijn gegenereerd uit twee priemgetallen.]
Bij symmetrische cryptografie heb je zowel voor het encrypten als het decrypten dezelfde sleutel nodig (zie bijvoorbeeld de caesar code). Het voordeel is dat deze methodes vaak snel zijn, maar het nadeel is, dat je eerst de geheime sleutel moet hebben voordat je kunt decrypten.
Hoe krijgt de ontvanger die geheime sleutel zonder secure communicatie? Dit is een kip-en-ei probleem.
Bij asymmetrische cryptografie heb je voor het encrypten en decrypten een verschillende sleutel nodig. De ene sleutel is public (bij iedereen bekend) en de andere sleutel is private (alleen bij de eigenaar bekend).
Het asymmetrische cryptografie mes snijdt aan twee kanten:
Je kunt 1 en 2 ook combineren. Je hebt dan een 1-op-1 veilige communicatie: Stel, A stuurt een bericht naar B, maar A wil zeker weten, dat niemand behalve B het kan lezen. A encrypt dus met de public key van B, kB. Ook wil B zeker weten, dat A het gestuurd heeft en niemand anders, dus A encrypt ook met zijn eigen private key, pA. B krijgt dus het volgende bericht:
c = m * kB * pA
B kan dit decrypten door zijn eigen private en A zijn public key toe te passen:
m' = c * pB * kA = m * kB * pA * pB * kA = m * (kB * pB) * (kA * pA) = m * 1 * 1 = m
A kan dus later niet ontkennen dat hij dit bericht gestuurd heeft, want hoe kwam zijn private key daar dan (bedenk dat er geen ander getal is, waarmee de public key van A 1 oplevert en dat alleen A deze private key heeft).
Als B ook nog een signed ontvangstbevestiging stuurt, dan weet A zeker dat B het bericht ontvangen heeft. Als beide berichten ook nog een timestamp bevatten, staan de volgende feiten vast:
Deze punten worden samen nonrepudiation genoemd.
Toch is het zo, dat asymmetrische encryptie relatief langzaam is. Het machtsverheffen met getallen van honderden cijfers is gewoon veel meer werk dan het tel-overal-2-bij-op symmetrische Caesar algoritme.
Je kunt het beste van 2 werelden nemen, door met een langzame asymmetrische encryptie de symmetrische sleutels veilig te versturen naar de ontvanger (dit heet de key-exchange of handshake). Hiermee los je het kip-en-ei probleem op. Daarna wordt met die sleutels een snelle symmetrische encryptie gebruikt.
Deze combinatie is de manier, waarop het meestal gebruikt wordt (HTTPS, WPA en andere secure communicatie).
Bij WEP (Wired Equivalent Privacy) moet je bij beide kanten een sleutel instellen. Die sleutel wordt voor encryptie gebruikt. Dit is dus een symmetrische encryptie.
Bij WPA-PSK (Wi-Fi Protected Access - PreShared Key) geef je ook bij beide kanten een sleutel, maar de zender gebruikt deze sleutel om een andere, willekeurige sleutel uit af te leiden. Deze tweede sleutel wordt via een asymmetrische encryptie naar de ontvanger gestuurd en gebruikt voor de verdere symmetrische encryptie. Met enige regelmaat wordt deze tweede sleutel vervangen en wordt er een nieuwe gestuurd.
Als twee computers, Alice en Bob, met elkaar communiceren en Alice wil weten of Bob nog steeds de juiste credentials (d.i. private key) heeft, dan kan Alice een willekeurige string naar Bob sturen. Dit wordt een Challenge (=uitdaging) genoemd. Bob moet deze dan encrypten met zijn private key (signen, dus) en terug sturen. Dit is de Challenge Response. Alice probeert dan te decrypten met Bobs public key en als dat lukt, heeft Bob nog de juiste private key. Lukt dat niet dan is Bob niet meer degene met de private key.
Zo’n Challenge kan in principe op elk willekeurig moment gegeven worden.
Een certificaat bestaat uit drie delen:
Een certificaat koppelt een fysieke entiteit aan een public key
en de signature garandeert deze koppeling.
Je public key zit dus in je certificaat, samen met een aantal
andere gegevens. De bij deze public key horende private key zit in een andere
file en verlaat je computer in principe nooit.
Als je mij dus een bericht wilt sturen, vraag je mijn certificaat, gebruikt die public key en ik heb de private key om te decrypten.
Een certificaat heeft een begin en eind datum. Bovendien kan de uitgever ervan (CA) het certificaat herroepen, zodat hij niet meer geldig is.
Als jij mij iets wilt sturen, heb jij mijn certificaat nodig. Dit krijg je door het aan mij te vragen (of ergens anders vandaan, zoals een database). Maar hoe weet jij dat jij mijn certificaat krijgt en niet dat van een hacker?
Stel, Alice wil €10.000 overmaken. Alice zet hiervoor een HTTPS verbinding op met Bank. Wat Alice niet weet is dat Eve (eavesdropper) meeluistert op het internet (ga er vanuit, dat dit eerder regel dan uitzondering is). Eve ziet dat Alice het certificaat van Bank opvraagt. Eve stuurt gauw haar eigen fake Bank-certificaat. Alice denkt dus dat zij met Bank communiceert en geeft haar wachtwoord. Op dat moment heeft Eve dus Alice haar wachtwoord en Alice heeft een probleem.
Hoe voorkom je dit nu? Hiervoor heb je nog een onafhankelijke derde (Certificate Authority, CA) nodig. Bank vraagt aan zo’n CA om het certificaat te signen met zijn private key. De CA controleert dat Bank is, wie hij zegt dat hij is en stuurt de Bank de signature. Deze signature verzekert dat de public key en de fysieke entiteit (Bank) bij elkaar horen.
Alice krijgt nu een certificaat en ziet dat een bepaalde CA dit gesigneerd heeft. Alice vraagt het certificaat van die CA en controleert de signature (het certificaat van de CA bevat de public key, waarmee de signature te verifiëren is). Als dit klopt, weet Alice dat dit inderdaad het certificaat van Bank is, volgens de CA. Als Alice de CA vertrouwt, vertrouwt Alice het Bank-certificaat ook.
Maar wie verzekert Alice dat het CA-certificaat te vertrouwen is? Eve kan natuurlijk dezelfde truc met het CA-certificaat uithalen en Alice een fake CA-certificaat sturen. Als Alice het niet vertrouwt, kan hij ook het CA-certificaat op dezelfde manier controleren. Het CA-certificaat is immers ook uitgegeven door een ‘hogere’ CA. Deze keten van certificaten wordt de Certificate Chain (Chain of Trust) genoemd en de betrouwbaarheid van elk certificaat is afgeleid uit de betrouwbaarheid van het certificaat van zijn CA.
Uiteindelijk komt Alice uit bij een super-CA (root CA), zoals bijvoorbeeld VeriSign of Thawte. Deze zijn zo groot en bekend, dat Alice hun certificaat waarschijnlijk al heeft (meegeleverd met de browser) en dan weet Alice zeker dat de hele keten zo betrouwbaar is als de root CA zelf.
Ook is het mogelijk, dat je je eigen certificaat signeert (je bent dan dus je eigen CA). Dit heet een self-signed certificate. Zo’n certificaat kun je wel gebruiken om te encrypten, maar de andere kant weet niet 100% zeker of de signatures wel correct zijn. Dit wordt veel gedaan door webservers (HTTPS).
Bron: www.anne-gert.nl.