Asymmetrische encryptie

Cyberboswachters

Tim Dams

Deze cursus werd gemaakt met hulp van AI-assistentie. Sommige afbeeldingen zijn door AI gegenereerd.

Symmetrische encryptie Het sleutelprobleem

Per eindpunt een aparte sleutel.

Aantal sleutels: \(n \times \frac{(n - 1)}{2}\)

15

sleutels voor 6 gebruikers

45

voor 10 gebruikers

4950

voor 100 gebruikers

Bij 6 gebruikers zijn er al 15 sleutels nodig.

Key distribution problem

Op de schaal van het Internet wordt sleutelmanagement onmogelijk.

Er is een andere oplossing nodig: asymmetrische encryptie.

Asymmetrische encryptie

Encryptie splitst in symmetrisch (1 sleutel om te encrypteren en te decrypteren) en asymmetrisch (publieke sleutel om te encrypteren, private om te decrypteren). Asymmetrisch is gemarkeerd.

Twee sleutels

Publieke sleutel

Iedereen mag hem gebruiken om berichten naar de eigenaar te encrypteren.

Private sleutel

Enkel de eigenaar kan ermee decrypteren.

Moet altijd geheim blijven (cfr. Kerckhoffs).

1976 · Diffie en Hellman Asymmetrische encryptie: werking

Enorme impact op beveiligde communicatie via het Internet.

Publieke crypto: Bob gebruikt de publieke sleutel van Alice om haar een beveiligd bericht te sturen.

De kist-metafoor

Tip

De publieke sleutel = een openstaande kist.

Iedereen kan er een boodschap in leggen en op slot klikken (encrypteren).

Enkel de eigenaar heeft de private sleutel om de kist te openen (decrypteren).

Een openstaande kist die iedereen kan dichtklikken, een kist op slot, en de eigenaar die de kist weer opent.

Drie toepassingen van publieke crypto

Encryptie

Versleutelen met de publieke sleutel van de ontvanger.

Bv. RSA.

Sleuteluitwisseling

Over een onveilig kanaal een symmetrische sleutel afspreken.

Bv. Diffie-Hellman.

Digitale handtekening

Tekenen met je private sleutel.

Bewijs van identiteit.

Digitale handtekening: concept

Het ondertekenen van een document met behulp van je private sleutel.

Enkel de eigenaar heeft de private sleutel: een geldige handtekening bewijst zijn identiteit (authenticatie) en toont dat het bericht niet werd aangepast (integriteit).

Sleuteluitwisseling Diffie-Hellman

Waarom sleuteluitwisseling?

Symmetrische crypto is sneller, maar hoe spreek je die sleutel veilig af?

Bij grote groepen loopt het sleutelbeheer vast. Diffie-Hellman laat twee partijen een gedeeld geheim (shared secret) afspreken over een onveilig kanaal.

Diffie-Hellman: werkwijze

  1. Publiek afspreken: priemgetal \(p\) en basis \(g\)
  2. Elk kiest een geheime waarde (per sessie)
  3. Elk stuurt een publieke waarde \(g^{geheim}\%p\)
  4. Combineren met de eigen geheime waarde
  5. Resultaat: een shared secret

Deze waarden zijn geen sleutelpaar zoals bij RSA: ze worden na de uitwisseling weggegooid.

Diffie-Hellman: rekenvoorbeeld

Publiek afgesproken: basis \(g = 7\) priemgetal \(p = 11\)

Stap Alice Bob
1 Kiest geheim getal A = 3 Kiest geheim getal B = 6
2 Berekent \(7^A\%11 = 343\%11 = 2\) (= X) Berekent \(7^B\%11 = 117649\%11 = 4\) (= Y)
3 Stuurt X=2 naar Bob Stuurt Y=4 naar Alice
4 Berekent \(Y^A\%11 = 4^3\%11 = 9\) Berekent \(X^B\%11 = 2^6\%11 = 9\)

9

het shared secret: enkel Alice en Bob kennen dit getal

Waarom werkt dit?

Dankzij de eigenschappen van de modulo-operator.

X en Y kunnen het resultaat zijn van gigantische berekeningen: een stroper heeft veel rekenwerk nodig om alle mogelijkheden te testen.

In de praktijk kiezen Alice en Bob véél grotere getallen dan 3 en 6.

Diffie-Hellman Verf mengen

  1. Publiek: een startkleur (geel)
  2. Elk kiest een geheime kleur
  3. Mengen en naar elkaar sturen
  4. Eigen geheime kleur toevoegen
  5. Beiden krijgen dezelfde eindkleur

Mengen is makkelijk, ontmengen praktisch onmogelijk. Digitaal speelt de modulo-berekening die rol.

Diffie-Hellman uitgelegd in filmpje

Alles samen uitgelegd

Asymmetrische encryptie RSA en ECC

RSA

1977

ontwikkeld door Rivest, Shamir en Adleman

1536-4096

bits sleutellengte

Relatief traag: vaak enkel gebruikt voor de sleuteluitwisseling, daarna schakel je over op een sneller symmetrisch cipher.

Gebaseerd op de modulo-operator, net als Diffie-Hellman.

RSA: sleutels aanmaken

  1. Kies twee priemgetallen: \(p=17\) en \(q=11\)
  2. Bereken \(N = p \times q = 187\)
  3. Kies een priemgetal \(e = 7\)
  4. Zoek \(d\) zodat \((7 \times d)\%160 = 1\) → \(d = 23\)

Algemeen: \((e \times d)\%((p-1) \times (q-1)) = 1\)

Publieke sleutel

\(N=187\) en \(e=7\) (openbaar)

Private sleutel

\(d=23\) (geheim!)

RSA: encryptie voorbeeld

Alice wil het ASCII-karakter X (waarde 88) naar Bob sturen.

Encryptie

Alice gebruikt de publieke sleutel: \(C = data^e\%N\)

\[C = 88^7\%187 = 11\]

Decryptie

Bob gebruikt zijn private sleutel: \(P = C^d\%N\)

\[P = 11^{23}\%187 = 88\]

= ASCII van X: het bericht is correct ontvangen!

RSA: waarom is dit veilig?

Vermenigvuldigen

\[123 \times 127 = 15621\]

Makkelijk.

Factoriseren

\[15621 = \; ? \times ?\]

Computationeel veel moeilijker.

RSA en cryptocurrencies

Wie je private sleutel heeft, kan je coins stelen.

Cryptocoins gebruiken dezelfde public crypto-concepten: je private sleutel is het bewijs dat de coins van jou zijn. Geef hem NOOIT aan derden.

Elliptic Curve Cryptografie (ECC)

Modernere asymmetrische crypto, gebaseerd op elliptische krommen. Veel kleinere sleutels voor hetzelfde beveiligingsniveau:

256 bits

ECC is even sterk als 3072 bits RSA

384 bits

ECC is even sterk als 7680 bits RSA

Kleiner = sneller, minder data, minder energie.

Ideaal voor mobiel IoT

ECC: toepassingen

ECDH

Diffie-Hellman sleuteluitwisseling via elliptische krommen.

ECDSA

Digitale handtekeningen, o.a. gebruikt door Bitcoin.

TLS/HTTPS

Moderne TLS gebruikt vrijwel altijd ECC voor de sleuteluitwisseling.

Quantumcomputers

Net als RSA is ook ECC kwetsbaar voor quantumcomputers.

Daarom werkt men aan post-quantum cryptografie. NIST publiceerde in 2024 de eerste standaarden.

Intermezzo Hashes en handtekeningen

Hashes

Een hashfunctie zet data om naar een code met vaste lengte, ongeacht de grootte van de input.

Twee zinnen die maar één teken verschillen geven via SHA-256 een totaal andere hash.

1 bit wijzigen → totaal andere hash identieke input → identieke hash

Hashes: eigenschappen

Niet omkeerbaar
Van hash terug naar de originele tekst is onmogelijk: een eenrichtingsfunctie.
Hash collision
Twee verschillende inputs geven dezelfde hash. Theoretisch onvermijdelijk, want de hash is korter dan de input.
Goede hashfunctie
Houdt het aantal collisions zo klein mogelijk.

Bekende hashfuncties

MD5

128 bits

Verouderd, veel collisions.

SHA-256

256 bits

Veilig.

SHA3-512

512 bits

Nieuwste standaard.

Een digitale hash is een ideaal middel om boodschappen digitaal te ondertekenen (integrity).

Digitale handtekeningen

Hoe weet je dat een bericht echt van de afzender komt?

Met een digital signature: de hash van het bericht, geëncrypteerd met de private sleutel van de afzender. De ontvanger verifieert met de bijhorende publieke sleutel.

Digitale handtekeningen

Boodschappen ondertekenen met je private sleutel.

Een handtekening maken en controleren

  1. Afzender berekent de hash van het bericht
  2. Hash versleutelen met de private sleutel = handtekening, mee met het bericht verstuurd
  3. Ontvanger berekent zelf de hash en ontsleutelt de handtekening met de publieke sleutel
  4. Gelijk? Dan is het bericht authentiek en onderweg niet aangepast

Digitale handtekeningen: hele proces

Digitale handtekeningen: rekenvoorbeeld

Gegeven sleutelpaar: publiek: \(e=5\), \(n=91\) privaat: \(d=29\)

Ondertekenen

Hash van de boodschap: \(m=35\)

\[s = m^d\%n = 35^{29}\%91 = 42\]

Verstuur: boodschap 35 + handtekening 42

Verifiëren

Ontvanger gebruikt de publieke sleutel \(e,n\):

\[42^e\%n = 42^5\%91 = 35\]

Hash komt overeen: het bericht is authentiek!

Het probleem met digitale handtekeningen

Publieke sleutels zijn… publiek. Hoe weet je dat een publieke sleutel echt bij persoon X hoort?

Een aanvaller kan:

  1. Een bericht onderscheppen en aanpassen
  2. Het ondertekenen met zijn eigen private sleutel
  3. De ontvanger wijsmaken dat zijn publieke sleutel van de originele afzender is

Man-in-the-middle bij handtekeningen

Eve misbruikt het impliciete vertrouwen dat zit ingebouwd in het digitale handtekening proces.

Vertrouwen Digitale certificaten

We hebben een manier nodig om de identiteit van de eigenaar van een publieke sleutel te verifiëren.

Digitaal certificaat

Een digitaal document dat een identiteit bindt aan een publieke sleutel.

Ondertekend door een trusted third party: vertrouw je die derde partij, dan vertrouw je het certificaat. Beschreven in de X.509-standaard.

Certificaat aanmaken

  1. Bob bewijst zijn identiteit bij een Registration Authority (RA): ID-kaart, paspoort, soms fysiek op kantoor
  2. De RA stuurt de aanvraag + Bobs publieke sleutel naar de Certification Authority (CA)
  3. De CA maakt het certificaat aan én ondertekent het

Wat zit er in een certificaat?

Leesbare inhoud

Bobs publieke sleutel en info over Bob en de CA.

Handtekening van de CA

Een hash van die inhoud, versleuteld met de private sleutel van de CA.

Het hele systeem van CA’s, RA’s, … voor het uitgeven, beheren en bewijzen van certificaten heet een Public Key Infrastructure (PKI).

Verificatie van certificaten

Zelf de hash berekenen → vergelijken met de handtekening, ontsleuteld met de publieke sleutel van de CA.

Links ondertekent de CA het certificaat, rechts vergelijkt de browser de zelf berekende hash met de ontsleutelde handtekening.

X.509: inhoud van een certificaat

Versie
van de standaard (doorgaans v3)
Serienummer
uniek binnen de CA
Signature algorithm
bv. SHA-256 met RSA
Issuer
de CA die het certificaat uitgaf
Validity
de geldigheidsperiode
Subject
de eigenaar (domeinnaam of persoon)
Public key
de publieke sleutel van de eigenaar
Extensions
gebruiksbeperkingen, alternatieve domeinnamen, …
Signature
de digitale handtekening van de CA

Chain of Trust

  1. De browser controleert het certificaat van de website via de CA
  2. Twijfel aan die CA? Dan controleer je haar certificaat bij de bovenliggende CA
  3. Zo ontstaat een keten van CA’s
  4. Bovenaan staat de root CA

Vertrouw je de root CA? Dan vertrouw je de hele keten. En vice versa!

Certificaat in de browser

Het certificaat tijdens het surfen.

HTTPS en certificaten werken in tandem: encryptie én identiteitsverificatie.

2017

pas dan biedt meer dan de helft van de websites HTTPS aan

Breach of Trust

Het ergste scenario: de private sleutel van een CA wordt gestolen.

Keten van CA's onder een root CA: wordt de private sleutel van een CA gestolen, dan worden alle certificaten eronder ongeldig.

Aanvallers maken dan certificaten op naam van de CA. Alle certificaten van die CA (en sub-CA’s!) worden ongeldig.

Wie vertrouw je nog?

In een notariskantoor drukt iemand ongemerkt een nagemaakt rood zegel op een stapel certificaten.

2011 Case: DigiNotar

De hack

Nederlandse CA gehackt. Valse certificaten voor o.a. google.com, ingezet om Iraanse Gmail-gebruikers te bespioneren.

De reactie

Browsers verwijderen DigiNotar als vertrouwde root CA. Alle DigiNotar-certificaten worden ongeldig, ook die van DigiD en de Nederlandse overheid.

Het gevolg

DigiNotar gaat binnen enkele weken failliet.

Digitale certificaten In de praktijk

Certificaten bekijken in de browser

  1. Klik op het slotje naast de URL
  2. Je ziet geldigheidsduur, CA, publieke sleutel, algoritmes, …
  3. Tab Certificeringspad = de chain of trust

Het certificaat van België.

Self-signed certificaten

Root CA’s hebben een self-signed certificate:

Verleend aan = Verleend door

Vertrouw je de root CA niet? Dan is de hele keten niet te vertrouwen.

Sectigo heeft een self-signed certificaat.

Soorten certificaten

SSL-certificaat

Bewijst de identiteit van een webserver.

Persoonlijk certificaat

Bewijst je eigen identiteit, bv. bij e-mail.

Code signing

Bewijst de echtheid van software.

Windows SmartScreen

Controleert automatisch het certificaat van applicaties.

Geen certificaat? Dan krijg je een waarschuwing.

Geen certificaat ≠ automatisch onveilig. Certificaten kosten geld en niet elke ontwikkelaar kan dat betalen.

Windows Certificate Manager

Bekijk welke certificaten lokaal geïnstalleerd zijn en welke vertrouwd worden.

Start de tool met certlm.msc.

Let er altijd op welke informatie je deelt via screenshots.

Web of Trust

Geen centrale autoriteit: gebruikers ondertekenen elkaars publieke sleutels.

Een gedecentraliseerd alternatief voor PKI, bekend van PGP/GPG.

Alice verifieert Bobs sleutel persoonlijk en ondertekent die met haar private sleutel: “Ik bevestig dat deze sleutel van Bob is.”

Web of Trust: vertrouwenspaden

  • Carol kent Bob niet, maar vertrouwt Alice
  • Alice heeft Bobs sleutel ondertekend
  • Via dat vertrouwenspad aanvaardt Carol Bobs sleutel
  • Zo ontstaat een web van onderlinge vertrouwensrelaties

Carol vertrouwt Alice, Alice ondertekent Bobs publieke sleutel, en zo aanvaardt Carol via een vertrouwenspad ook Bobs sleutel.

PKI vs. Web of Trust

PKI

  • Hiërarchisch: vertrouwen top-down
  • Validatie door Certificate Authorities
  • Zwak punt: 1 CA gehackt = iedereen getroffen
  • HTTPS, S/MIME, code signing

Web of Trust

  • Peer-to-peer
  • Validatie door de gebruikers zelf
  • Zwak punt: vergt actieve deelname
  • PGP/GPG e-mail, softwarepakketten

WoT bleek moeilijk schaalbaar: key signing parties, vertrouwenspaden zoeken, … Daarom domineert PKI op het Internet.

Veilig surfen HTTPS en TLS

Certificaten vormen het hart van een veilige manier van surfen.

HTTPS en TLS

HTTPS = HTTP + een beveiligde encryptietunnel.

443

de poort voor HTTPS

80

de klassieke poort voor HTTP

TLS
Transport Layer Security: het protocol dat de tunnel opzet
SSL
Secure Sockets Layer: de voorganger van TLS

Wat doet TLS?

  1. Identiteitscontrole: het certificaat (asymmetrische crypto) verifieert de website
  2. Sleuteluitwisseling: een gemeenschappelijke sleutel afspreken (Diffie-Hellman, Elliptic Curve, …)
  3. Tunnel: vanaf nu kunnen derden de trafiek niet meer sniffen

De erg belangrijke TLS tunnel tijdens het surfen met HTTPS.

TLS: het beste van beide werelden

Asymmetrisch

Veilige sleuteluitwisseling, maar traag.

Symmetrisch

Snelle data-encryptie.

TLS/HTTPS combineert de sterktes van beide soorten crypto.

Meer weten? Bekijk de briljante visualisatie op tls.ulfheim.net

Mutual TLS (mTLS)

Gewone HTTPS

Enkel de server heeft een certificaat.

mTLS

Ook de client authenticeert met een certificaat. De server weet zeker wie de client is.

Typisch gebruikt in: bankomgevingen e-government bedrijfs-VPN’s backend-servers

Bij mTLS toont niet enkel de server maar ook de client een certificaat, beide gecontroleerd bij dezelfde CA.

HTTPS: nadelen

HTTPS maakt je verbinding een pak veiliger, maar voor je ISP en de website zijn er ook nadelen.

Geen caching

Alles is geëncrypteerd: je ISP kan niet meer cachen.

Meer trafiek

De website moet meer trafiek verwerken, want er is geen tussenliggende cache.

Een extra deurtje, enkel voor de goeden?

Achteraan een goed beveiligd huis bouwen ambtenaren een klein rood deurtje in, terwijl een inbreker vanuit de struiken toekijkt.

2025 E2E-encryptie onder druk: Apple en de UK

End-to-end encryptie (E2EE): enkel zender en ontvanger kunnen de data lezen.

  1. De Britse overheid eist een backdoor in Apple’s iCloud-encryptie
  2. Apple weigert die backdoor
  3. Apple schakelt E2EE (Advanced Data Protection) uit in het VK

iMessage, FaceTime en iCloud Keychain behouden wel E2EE.

Een backdoor die enkel voor “de goeden” werkt, bestaat niet.

Een achterpoortje verzwakt de beveiliging voor alle gebruikers. Dat is in strijd met Kerckhoffs principe.

2022 Chat Control: ook in de EU

Het voorstel

EU-voorstel: de Child Sexual Abuse Regulation.

Verplicht scannen van alle chatberichten, ook E2E-versleutelde.

De critici

Technisch is dit een backdoor of client-side scanning (spyware).

Na jarenlange controverse werd het verplicht scannen van E2EE in 2025 afgezwakt.

Je kan niet tegelijk echte E2E-encryptie garanderen én berichten laten meelezen.

Man-in-the-middle: mitmproxy

mitmproxy: Linux-tool voor een MITM-aanval op HTTPS.

  1. Aanvaller nestelt zich tussen client en website
  2. Zet eigen TLS-tunnels op naar beide kanten
  3. Kan alle trafiek lezen en aanpassen

Een man-in-the-middle aanval met TLS.

Mitmproxy: verdediging

De aanvaller kan geen geldige certificaten genereren.

De browser geeft dan een waarschuwing.

Negeer nooit certificaat­waarschuwingen in je browser!

De waarschuwing die Chrome genereert wanneer het een, potentiële, mitm-aanval detecteert.

Conclusie

  • Asymmetrische crypto lost het sleuteldistributieprobleem op
  • Twee sleutels: publiek (encryptie) en privaat (decryptie + handtekening)
  • Digitale handtekeningen en certificaten bewijzen identiteit
  • TLS/HTTPS combineert asymmetrisch en symmetrisch voor snelle, veilige communicatie
  • De chain of trust (CA’s) is de ruggengraat van vertrouwen op het Internet

Onthoud

Bescherm je private sleutel, verifieer certificaten en negeer nooit browserwaarschuwingen.