Beveiliging in computernetwerken

Een bericht kan vertrouwelijk zijn, maar toch worden gewijzigd of van een bedrieger afkomstig zijn. Veilige communicatie vereist daarom verschillende eigenschappen, die elk een andere vraag over de uitwisseling beantwoorden.

Benoem de eigenschap die gevaar loopt

Alice en Bob zijn de communicerende partijen; Trudy is de aanvaller. Een passieve aanvaller onderschept verkeer zonder het te veranderen. Een wachtwoord lezen is afluisteren. Uit verbindingstijden afleiden dat iemand een druk werkschema heeft, is verkeersanalyse, ook als de inhoud versleuteld is. Een actieve aanvaller voegt pakketten in, wijzigt of verwijdert ze of verstuurt ze opnieuw. Bij adresvervalsing geeft de aanvaller een valse bronidentiteit op; bij kaping neemt de aanvaller een bestaande uitwisseling over; bij overspoeling probeert de aanvaller middelen uit te putten.

Internetrouters sturen pakketten doorgaans door zonder vast te stellen of hun bronadressen echt zijn. Pakketten gaan ook door netwerken waarover geen van beide gebruikers controle heeft. Bij wifi kan een ander apparaat binnen radiobereik verzonden frames onderscheppen. Protocollen moeten communicatie beschermen, ook wanneer een aanvaller het pad beheerst.

Volg een onbeschermde aanmelding

Bob maakt verbinding met een caféhotspot en logt in via onversleuteld HTTP. Trudy leest het wachtwoord: de vertrouwelijkheid is aangetast. Ze verandert een downloadlink in het antwoord: de integriteit is aangetast. Als ze een valse hotspot met de naam van het café aanbiedt, kan Bob ook de identiteit van het toegangspunt niet betrouwbaar controleren. Alleen het wachtwoord versleutelen zou niet al deze problemen oplossen. Een aanvaller kan sommige versleutelde berichten wijzigen zonder ze te begrijpen en kan een onderschept authenticatiebericht ongewijzigd opnieuw versturen.

Houd de sleutel geheim

Het principe van Kerckhoffs stelt dat de beveiliging stand moet houden als het algoritme bekend wordt. De sleutel is het geheim. Een zelfgemaakt geheim algoritme kan uit software worden achterhaald; bovendien is een volledig algoritme veranderen en verspreiden moeilijker dan een sleutel vervangen. Een uitgelekte sleutel vervangen beschermt toekomstig verkeer, maar maakt opnamen onder de oude sleutel niet veilig.

Ook de kennis van de aanvaller is van belang. Een aanval met alleen cijfertekst begint met onderschepte versleutelde berichten. Bij een aanval met bekende klare tekst heeft de aanvaller daarnaast bijbehorende oorspronkelijke berichten, zoals voorspelbare HTTP/1.1-tekst die met “GET /” begint. Bij een aanval met gekozen klare tekst kan de aanvaller versleutelde versies van zelfgekozen berichten verkrijgen. Moderne versleuteling is ontworpen om deze sterkere aanvallen te weerstaan.

Bepaal welk deel van het pad wordt beschermd

Wifi- en mobiele beveiliging beschermen een radioverbinding. TLS beschermt communicatie tussen applicatie-eindpunten. IPsec beschermt geselecteerd IP-verkeer tussen hosts of gateways. Bescherming op berichtniveau, zoals beveiligde e-mail, kan tijdens de opslag bij een bericht blijven. Een beveiligde draadloze verbinding beschermt niet de rest van een internetroute: nadat een toegangspunt de verbindingsbeveiliging heeft verwijderd, moet een ander mechanisme het verdere verkeer beschermen.

Een symmetrisch versleutelingsalgoritme gebruikt aan beide kanten dezelfde geheime sleutel. Klare tekst is het oorspronkelijke bericht; cijfertekst is de versleutelde vorm. Schrijf versleuteling als $c=E_{K_S}(m)$ en ontsleuteling als $m=D_{K_S}(c)$: de sleutel wordt gedeeld, maar de twee bewerkingen maken elkaar ongedaan.

Sleutelgrootte en structurele zwakheden

Een caesarverschuiving van 3 verandert “KOM OM HET MIDDAGUUR” in “NRP RP KHW PLGGDJXXU”. Door alle 25 bruikbare verschuivingen te proberen, kraak je de versleuteling. Een substitutieversleuteling heeft $26!\approx \mathrm{4,03}\times {10}^{26}$ sleutels, maar behoudt de letterfrequenties. Een aanvaller kan herhaalde letters en veelvoorkomende woorden gebruiken om de vervanging te achterhalen zonder elke sleutel te proberen. De grootte van de sleutelruimte bewijst op zichzelf niet dat de versleuteling veilig is.

AES is een blokversleutelingsalgoritme met blokken van 128 bits en sleutels van 128, 192 of 256 bits. DES had blokken van 64 bits en een sleutel van 56 bits; in 1998 werd een DES-sleutel met uitputtend zoeken gekraakt en DES en Triple DES zijn niet meer voor standaardgebruik toegestaan. Elke extra sleutelbit verdubbelt het werk voor uitputtend zoeken. Bij ${10}^{12}$ pogingen per seconde duurt het doorzoeken van alle DES-sleutels ongeveer $2^{56}\mathrm{/}{10}^{12}\approx 72.000$ seconden, oftewel 20 uur; gemiddeld wordt de sleutel na de helft van die tijd gevonden. Alle AES-128-sleutels doorzoeken met die snelheid duurt ongeveer $\mathrm{1,1}\times {10}^{19}$ jaar.

De modus verandert de bescherming van berichten

Een werkingsmodus verwerkt meer dan één blok.

Het eerste blok van CBC gebruikt een initialisatievector, of IV, in plaats van een vorig blok cijfertekst. De IV wordt openlijk verzonden; onvoorspelbaarheid en nieuwheid zijn van belang, niet geheimhouding. Willekeurige waarden verbergen directe gelijkheidspatronen tussen berichten. Ze detecteren op zichzelf geen manipulatie.

Reken hergebruik van een sleutelstroom door

Stel dat twee berichten dezelfde sleutelstroom $k$ gebruiken. Hun cijferteksten zijn $c_1=m_1\oplus k$ en $c_2=m_2\oplus k$. Door daarop XOR toe te passen valt de herhaalde sleutelstroom weg:

Als je nu één klare tekst kent, kun je de andere achterhalen. De herhaalde IV's van WEP veroorzaakten dit soort problemen. Een langere versleutelingssleutel verhelpt een herhaalde sleutelstroom niet.

AEAD, geauthenticeerde versleuteling met geassocieerde gegevens, combineert vertrouwelijkheid met integriteit. AES-GCM en ChaCha20-Poly1305 authenticeren de cijfertekst en eventuele geassocieerde gegevens. Geassocieerde gegevens, zoals een routeringsveld, blijven leesbaar maar kunnen niet worden gewijzigd zonder dat de verificatie mislukt. TLS 1.3 gebruikt AEAD voor elk beschermd record.

Verdeel het geheim

Voor snelle bulkversleuteling is nog steeds een gedeelde sleutel nodig. Als elk paar van $n$ gebruikers een andere sleutel nodig heeft, is het totaal $n(n-1)\mathrm{/}2$. Voor 100 gebruikers zijn dat 4.950 sleutels. Met publiekesleutelmechanismen kunnen partijen sessiesleutels tot stand brengen zonder vooraf voor elk paar een afzonderlijk geheim te verdelen.

Bob publiceert $K_B^{+}$ en houdt $K_B^{-}$ geheim. Alice kan voor Bob versleutelen zonder eerst een geheim met hem te delen. Het moet rekenkundig onhaalbaar zijn om de privésleutel uit de publieke sleutel te achterhalen.

Reken een eenvoudig RSA-voorbeeld uit

RSA begint met priemgetallen $p$ en $q$. Bereken $n=pq$ en $z=(p-1)(q-1)$. Kies een publieke exponent $e$ die onderling ondeelbaar is met $z$ en zoek vervolgens $d$ zodat $ed<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>z=1$. De publieke sleutel is $(n,e)$; de privésleutel is $(n,d)$. Voor een berichtgetal kleiner dan $n$:

Gebruik de kleine voorbeeldpriemgetallen 11 en 13. Dan is $n=143$ en $z=120$. Kies bij $e=7$ voor $d=103$, want $7\times 103=721=6\times 120+1$. Voor $m=9$ geeft herhaald kwadrateren $9^2<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>143=81$ en $9^4<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>143=126$. Combinatie van de machten geeft $9^7<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>143=48$. Ontsleuteling geeft ${48}^{103}<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>143=9$.

Deze getallen maken de berekeningen zichtbaar; RSA in de praktijk gebruikt moduli van ten minste 2.048 bits. Door de modulus te ontbinden vind je de priemgetallen en kun je de sleutel achterhalen. Echte RSA-versleuteling gebruikt ook willekeurige OAEP-opvulling: RSA zoals in leerboeken beschreven herhaalt zonder opvulling de cijfertekst bij een herhaald bericht.

Kom met Diffie–Hellman een geheim overeen

Diffie–Hellman brengt een gedeeld geheim tot stand zonder dat geheim te versturen. Alice en Bob publiceren een priemgetal $p$ en een generator $g$. Alice houdt $a$ geheim en verstuurt $A=g^a<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>p$. Bob houdt $b$ geheim en verstuurt $B=g^b<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>p$. Alice berekent $B^a<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>p$ en Bob berekent $A^b<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>p$; beiden krijgen $g^{ab}<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>p$.

Voor $p=29$, $g=2$, $a=5$ en $b=12$ verstuurt Alice 3 en Bob 7. Alices berekening is $7^5<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>29=16$; die van Bob is $3^{12}<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>29=16$. Hun kleine voorbeeld is gemakkelijk te kraken; grote groepen maken het achterhalen van de geheime exponenten onhaalbaar. Uitwisselingen met elliptische krommen zoals X25519 dienen hetzelfde doel met kortere sleutels.

Authenticeer de uitwisseling

Gewoon Diffie–Hellman stelt de identiteit van geen van beide deelnemers vast. Trudy kan haar eigen publieke waarden in de plaats zetten en twee afzonderlijke gedeelde geheimen maken, één met Alice en één met Bob. Vervolgens leest en herversleutelt ze het verkeer. Een geauthenticeerd protocol koppelt de uitgewisselde waarden aan vertrouwde identiteiten, met handtekeningen en certificaten of met een bestaand gedeeld geheim.

Protocollen gebruiken hybride versleuteling: bewerkingen met publieke sleutels brengen een sessiesleutel tot stand en AES of ChaCha20 verwerkt de bulkgegevens. RSA kan een willekeurige sessiesleutel transporteren, maar als de RSA-privésleutel later wordt gestolen, komen opgenomen uitwisselingen bloot te liggen. Nieuwe tijdelijke Diffie–Hellman-waarden, die na gebruik worden verwijderd, bieden voorwaartse geheimhouding tegen latere diefstal van lang gebruikte authenticatiesleutels.

Een voldoende grote kwantumcomputer zou RSA en klassiek Diffie–Hellman kraken. ML-KEM, in 2024 door NIST gestandaardiseerd in FIPS 203, is bedoeld voor postkwantumsleutelovereenkomst. Een hybride combinatie zoals X25519MLKEM768 combineert klassieke en postkwantumcomponenten. Dit gebruik van “hybride” beschrijft twee mechanismen voor sleutelovereenkomst; bulkgegevens gebruiken nog steeds symmetrische versleuteling, waaronder sleutels van 256 bits voor een ruime beveiligingsmarge.

Een integriteitscontrole moet bestand zijn tegen een doelgerichte aanvaller, niet alleen tegen onopzettelijke fouten. Een netwerkcontrolesom en een cryptografische hash dienen verschillende doelen en geen van beide authenticeert op zichzelf een bericht.

Begrijp de eigenschappen van een hash

Een cryptografische hashfunctie zet een bericht van willekeurige lengte om in een hashwaarde van vaste grootte. SHA-256 levert 256 bits op, meestal geschreven als 64 hexadecimale cijfers. Goede hashfuncties hebben drie verschillende eigenschappen:

Botsingen bestaan omdat een eindige verzameling hashwaarden meer mogelijke berichten vertegenwoordigt. Veiligheid betekent dat het onhaalbaar is een bruikbare botsing te vinden. Voor MD5 en SHA-1 bestaan praktische botsingsaanvallen; ze zijn ongeschikt voor handtekeningen en certificaten. SHA-3 is een andere moderne familie van hashfuncties.

Kleine wijzigingen in een bericht verspreiden zich over de hashwaarde: dit is het lawine-effect. Als “Pay Ana 100” verandert in “Pay Ana 900”, veranderen 124 bits van de SHA-256-uitvoer; de hashwaarden beginnen met ECD0D31E en 21736708. De internetcontrolesom van zowel “PAY 1290” als “PAY 9012” is daarentegen 0xEC3B: als je de betreffende 16-bits woorden verwisselt, blijft hun som gelijk. Een controlesom die is ontworpen om willekeurige beschadiging te detecteren, is gemakkelijk opzettelijk gelijk te houden.

Voeg het geheim toe dat een aanvaller niet heeft

Een bericht en de bijbehorende hash openlijk versturen beschermt niet tegen actieve manipulatie. Trudy vervangt zowel het bericht als de hashwaarde, zodat de herberekening van de ontvanger slaagt. Een berichtauthenticatiecode, of MAC, voegt een geheime authenticatiesleutel toe die Alice en Bob delen.

Alice verstuurt $m$ en $\mathrm{M}\mathrm{A}\mathrm{C}(s,m)$. Bob berekent een tag uit het ontvangen bericht en zijn eigen exemplaar van $s$ en vergelijkt vervolgens de tags. Als Trudy “Pay Ana 100” verandert in “Pay Ana 900”, berekent Bob de tag voor de gewijzigde tekst. De oude tag die Trudy heeft gekopieerd, komt daar niet mee overeen. Het bericht kan nog steeds leesbaar zijn: een MAC biedt integriteit en authenticatie van een sleutelhouder, geen vertrouwelijkheid.

HMAC gebruikt een hashfunctie in twee geneste toepassingen met een sleutel. HMAC-SHA256 is een standaardkeuze. Eenvoudigweg $H(s\mathrm{\parallel }m)$ gebruiken met SHA-256 is onveilig: door lengteverlenging kan een aanvaller mogelijk bytes toevoegen en een bijpassende tag berekenen zonder de sleutel te achterhalen. De constructie van HMAC voorkomt dat probleem.

Onderscheid authenticiteit van recentheid

Een oud bericht met de oorspronkelijke MAC heeft nog steeds een geldige tag. Om herhaling af te wijzen, authenticeer je een volgnummer of een nieuwe uitdaging samen met het bericht en controleert de ontvanger die waarde. Een niet-geauthenticeerd nummer toevoegen is onvoldoende, omdat Trudy het kan veranderen.

Beide houders van de gedeelde sleutel kunnen geldige tags maken. Een derde kan een MAC daarom niet gebruiken om te bepalen welke houder een bericht heeft geschreven. Digitale handtekeningen bieden dat openbaar verifieerbare bewijs. Als je versleuteling met een afzonderlijke MAC combineert, gebruik dan afzonderlijke sleutels en bereken de MAC na het versleutelen over de cijfertekst; een AEAD-constructie biedt een geïntegreerd alternatief.

Met een digitale handtekening kan iedereen bewijs controleren dat met één privésleutel is gemaakt. De verifiërende partij heeft zowel een deugdelijke handtekeningcontrole nodig als een betrouwbare koppeling tussen de publieke sleutel en de identiteit die deze vertegenwoordigt.

Onderteken en verifieer een bericht

De ondertekenaar gebruikt een privésleutel; de verifiërende partij gebruikt de bijbehorende publieke sleutel. Handtekeningen binden hun bewijs aan het bericht, zodat verificatie na een wijziging mislukt. De privésleutel moet onder controle van de ondertekenaar blijven. Dit ondersteunt onweerlegbaarheid: onafhankelijk verifieerbaar bewijs van ondertekening, anders dan bij een MAC die beide houders van de gedeelde sleutel kunnen maken.

Schema's verwerken een hashwaarde of gecodeerde representatie van het bericht. In een vereenvoudigd RSA-model is de handtekening $K_B^{-}(H(m))$. De ontvanger berekent de hashwaarde en vergelijkt die met de waarde die met Bobs publieke sleutel wordt teruggewonnen. Echte RSA-handtekeningen voegen een codering toe, zoals RSASSA-PSS; ECDSA en Ed25519 gebruiken andere rekenmethoden. Ondertekenen is geen algemene methode om een bericht met een privésleutel te versleutelen.

Neem voor een eenvoudige RSA-sleutel met $n=143$, $e=7$ en $d=103$ een hashwaarde van 20. Bob berekent $\sigma ={20}^{103}<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>143=58$. Alice krijgt ${58}^7<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>143=20$ en vergelijkt dit met haar eigen hashwaarde. Als de gewijzigde tekst hashwaarde 21 heeft, komt de teruggewonnen waarde 20 niet overeen. Botsingsbestendigheid is van belang omdat anders twee berichten met dezelfde hashwaarde ook dezelfde invoer voor de handtekening kunnen hebben.

Koppel een sleutel aan een naam

Trudy kan een volledig geldig sleutelpaar genereren. Als ze de publieke sleutel daarvan “Bob” noemt, onthult een geslaagde handtekeningverificatie alleen de verwisseling niet. Een certificaat koppelt een identiteit aan een publieke sleutel met een handtekening van een certificeringsautoriteit.

Een X.509-certificaat voor een website bevat domeinnamen in het veld voor alternatieve subjectnamen, de publieke sleutel van het subject, een uitgever, geldigheidsdatums en de handtekening van de uitgever. Een server levert normaal gesproken het eindcertificaat en tussencertificaten. De client controleert deze keten tot aan een rootcertificaat dat al wordt vertrouwd in het besturingssysteem of de browser. De eigen handtekening van een rootcertificaat maakt het niet vertrouwd; de opname in de opslag van vertrouwensankers vormt dat uitgangspunt voor vertrouwen.

De verifiërende partij controleert de handtekeningen in de keten, de geldigheidsdatums, de bedoelde naam, het toegestane gebruik en, waar beschikbaar, informatie over intrekking. Een keten die eindigt bij een onbekend rootcertificaat wordt niet vertrouwd alleen omdat de handtekeningen wiskundig geldig zijn.

Vereis bewijs van sleutelbezit

Certificaten zijn openbaar en kunnen worden gekopieerd. Een server moet ook aantonen dat hij de bijbehorende privésleutel beheert door nieuwe handshakegegevens te ondertekenen. Met alleen een gestolen certificaatbestand kun je die handtekening niet maken. Een gewoon geldig websitecertificaat bevestigt dat de houder de domeinnaam beheert; het bevestigt niet dat de inhoud of het bedrijf achter de website eerlijk is.

Eindpuntauthenticatie draait om de vraag wie er nu deelneemt. Een oud geldig bericht kan bewijzen dat iemand ooit een sleutel bezat, maar niet dat de huidige zender die sleutel bezit.

Kraak de zwakke versies

Alice stuurt eerst “Ik ben Alice”. Trudy kan dezelfde woorden versturen. Het bron-IP-adres van Alice toevoegen werkt niet, omdat een datagram een vervalst adres kan bevatten. Een wachtwoord versturen stelt het bloot aan een waarnemer. Een vast wachtwoord versleutelen verbergt de inhoud, maar laat een herbruikbaar bewijs achter: Trudy neemt de cijfertekst op en verstuurt die bij een volgende aanmelding.

Dit is een herhalingsaanval. De aanvaller ontsleutelt of verandert het oude bewijs niet. De zwakte is dat Bob dezelfde bytes in een nieuwe sessie accepteert. Een sterker versleutelingsalgoritme zou die protocolfout niet verhelpen.

Laat het bewijs van deze poging afhangen

Bob stuurt een nieuwe, onvoorspelbare nonce, een uitdaging die in deze authenticatiecontext één keer wordt gebruikt. Alice stuurt een waarde terug waarvoor haar geheime sleutel nodig is, zoals een HMAC van de uitdaging. Bob berekent het verwachte antwoord met zijn exemplaar van de sleutel. Een antwoord dat van een eerdere uitdaging is gekopieerd, komt niet overeen.

Bijvoorbeeld: de uitdaging van maandag is 0x7F3A91C2. Trudy onderschept het geldige antwoord daarop. Op dinsdag stuurt Bob 0x0B66E4D9. Het antwoord van maandag opnieuw versturen mislukt, omdat de verwachte tag van dinsdag uit andere bytes wordt berekend. De korte hexadecimale waarden illustreren de uitwisseling; echte uitdagingen hebben voldoende willekeurige bits nodig om bruikbare voorspelling of herhaling te voorkomen.

Onvoorspelbaarheid voorkomt ook dat antwoorden vooraf worden verzameld. Als Bobs volgende uitdaging gemakkelijk te raden is, kan Trudy zich als Bob voordoen, Alice vragen die toekomstige uitdaging te beantwoorden en het verzamelde antwoord later aan Bob geven. Een uitdaging moet aan de huidige protocoluitwisseling zijn gekoppeld en niet alleen van de vorige verschillen.

Authenticeer met publieke sleutels

Alice kan een nieuwe uitdaging met haar privésleutel ondertekenen. Bob verifieert de handtekening met haar echte publieke sleutel. Als Bob een vervangende publieke sleutel accepteert die Trudy heeft gegeven, kan Trudy Bobs uitdaging zelf ondertekenen. Certificaten leggen de koppeling tussen identiteit en sleutel vast; de nieuwe handtekening bewijst dat de sleutel nu wordt bezeten.

Bij wederzijdse authenticatie bewijzen beide communicatiepartners hun identiteit. Een protocol moet hun rollen onderscheiden en bewijzen aan de sessie binden, zodat het antwoord van de ene partij niet eenvoudig als dat van de andere kan worden teruggestuurd. Gewone web-TLS authenticeert meestal de server met een certificaat; de gebruiker authenticeert zich daarna binnen dat beschermde kanaal met een wachtwoord of passkey. Verbindingen tussen diensten en VPN's authenticeren vaak beide eindpunten.

Bescherm wat na het inloggen komt

Geslaagde authenticatie beschermt later onversleuteld verkeer niet. Trudy zou kunnen wachten tot het inloggen is voltooid en daarna opdrachten invoegen of de verbinding kapen. Veilige handshakes brengen sessiesleutels tot stand en daaropvolgende berichten krijgen integriteitsbescherming die aan die sessie is gekoppeld.

Uitdaging-antwoordauthenticatie maakt een zwak menselijk wachtwoord ook niet automatisch sterker. Als een waarnemer een onderschept antwoord voor elke wachtwoordpoging opnieuw kan berekenen, kan die een offline woordenboekaanval uitvoeren. De controle op recentheid stopt herhaling, terwijl een sterk geheim of een geschikte met een wachtwoord geauthenticeerde uitwisseling het raden tegengaat; de twee beschermingen lossen verschillende problemen op.

TLS biedt twee applicatieprocessen een vertrouwelijk, geauthenticeerd kanaal over een betrouwbare bytestroom. Bij het gebruikelijke HTTPS gebruikt HTTP TLS over TCP, normaal gesproken op poort 443. Een applicatiebibliotheek zoals OpenSSL of BoringSSL verzorgt TLS; TCP transporteert de bytes zonder ze te interpreteren.

Breng sleutels tot stand en bescherm vervolgens records

Een handshake authenticeert de communicatiepartner en brengt gedeeld sleutelmateriaal tot stand. Sleutelafleiding zet dat materiaal om in afzonderlijke geheimen voor handshakeverkeer en applicatiegegevens, met verschillende sleutels voor elke richting. Een uitgaand record van Alice kan niet eenvoudig worden teruggestuurd als een record van Bob, omdat de ontvangende richting andere bescherming gebruikt.

TLS splitst gegevens in records, zodat de ontvanger telkens één deel kan verifiëren. Een record met klare tekst bevat maximaal $2^{14}=16.384$ bytes aan inhoud. De korte header bevat een type, een versieveld voor compatibiliteit en de lengte. Versleuteling voegt extra gegevens toe, zodat een versleuteld record groter is dan de oorspronkelijke inhoud. In TLS 1.3 onthult het buitenste type van een beschermd record niet rechtstreeks het ingesloten inhoudstype voor applicatiegegevens of handshakegegevens.

TLS 1.3 vereist AEAD. De ontvanger verifieert de authenticatietag van een record voordat hij de klare tekst aan de applicatie doorgeeft. Als Trudy een beschermd HTTP-verzoek verandert, slaagt de controle van de tag niet: de ontvanger beëindigt de verbinding en gebruikt bad_record_mac voor een fout in de recordbescherming. TLS detecteert verstoring; het zet kwaadwillig gewijzigde bytes niet terug in een geldig verzoek.

Tel records in elke richting

Elke zender en ontvanger houdt een impliciet volgnummer voor records bij. Dat wordt niet in de TLS-recordheader verstuurd. TLS 1.3 past XOR toe op het volgnummer en een IV per richting om de AEAD-nonce te maken. Als een oud record op een nieuwe positie wordt herhaald, wordt het verkeerde verwachte nummer gebruikt en mislukt de authenticatie. Het verwijderen of opnieuw ordenen van beschermde records verstoort op vergelijkbare wijze de verwachte volgorde wanneer latere bytes worden verwerkt.

De volgnummers van TCP verzorgen nog steeds de gewone aflevering en herordening. Ze authenticeren de communicatiepartner niet: een aanvaller die het pad beheerst, kan TCP-headers vervalsen. De recordtelling van TLS is gekoppeld aan bescherming met een geheime sleutel, dus geslaagde TCP-aflevering betekent op zichzelf niet dat TLS-verificatie slaagt.

Detecteer een onvolledig einde

Stel dat Bob een document verwacht, maar de TCP-verbinding halverwege wordt afgesloten. Een vervalste FIN of een verbroken verbinding kan de transportaflevering beëindigen zonder te bewijzen dat de TLS-zender klaar was. TLS gebruikt de beschermde melding close_notify om een ordelijk einde van de zendstroom aan te geven. Zonder die melding moet de ontvanger rekening houden met mogelijke afkapping en de volledigheidsregels van de applicatie gebruiken; een onverwacht bestandseinde van TCP is geen geauthenticeerde eindmarkering.

Een aanvaller kan altijd pakketten verwerpen en de voortgang stoppen. Vertrouwelijkheid en integriteit garanderen geen beschikbaarheid. De volledige lengte van een HTTP-bericht kan een applicatie helpen herkennen dat één bericht is aangekomen, maar dat is een afzonderlijke controle naast de ordelijke afsluiting van TLS.

Onderscheid verwante protocollen

TLS 1.3 is gespecificeerd in RFC 9846, dat RFC 8446 in 2026 heeft vervangen. TLS 1.2 is nog in gebruik; SSL 2.0/3.0 en TLS 1.0/1.1 worden niet meer aanbevolen. DTLS past het beveiligingsontwerp aan voor datagrammen. QUIC voert de TLS 1.3-handshake uit binnen zijn transportprotocol op basis van UDP en beschermt daarna zelf QUIC-pakketten; het verstuurt geen gewone TLS-over-TCP-records via UDP.

Een TLS-handshake moet een geheim tot stand brengen en laten zien van wie dat geheim is. In een volledige TLS 1.3-uitwisseling op basis van certificaten levert tijdelijke sleutelovereenkomst nieuw sleutelmateriaal en binden handtekeningen de onderhandeling aan de identiteit van de server.

Volg de berichtenreeksen

1. ClientHello biedt versies, combinaties van AEAD-algoritmen, sleuteluitwisselingsgroepen, handtekeningalgoritmen, willekeurige gegevens en één of meer key_share-waarden aan. Meestal noemt het bericht de server via SNI.
2. ServerHello selecteert parameters en levert de sleutelwaarde van de server. Beide communicatiepartners berekenen gedeeld sleutelmateriaal en leiden daaruit verkeerssleutels voor de handshake af.
3. De server stuurt versleutelde berichten EncryptedExtensions, Certificate, CertificateVerify en Finished. CertificateVerify ondertekent gestructureerde invoer met daarin de hash van alle uitgewisselde handshakeberichten; Finished authenticeert die berichten met een afgeleide MAC-sleutel.
4. De client controleert de keten, servernaam, handtekening en Finished en stuurt daarna een eigen Finished. Applicatieverkeer gebruikt afzonderlijk afgeleide verkeersgeheimen.

Het certificaat van de server koppelt een naam aan een publieke sleutel. CertificateVerify bewijst dat de privésleutel in deze uitwisseling wordt beheerd. Finished detecteert verstoring van de vastgelegde onderhandeling. Dit zijn afzonderlijke controles: een gedeeld geheim met succes afleiden stelt de identiteit van de server niet vast.

Tel de rondlooptijden

Bij een RTT van 40 ms en zonder verwerkings- en transmissievertraging duurt het opzetten van TCP 40 ms en voegt een volledige TLS 1.3-handshake 40 ms toe. De client verstuurt het verzoek na 80 ms; een antwoord kan rond 120 ms terugkomen. Een volledige TLS 1.2-handshake voegt na TCP twee RTT's toe, zodat de overeenkomstige tijden 120 ms en 160 ms zijn. QUIC combineert het opzetten van het transportprotocol met de TLS-handshake, zodat een nieuwe verbinding het verzoek na één RTT, na 40 ms, kan versturen.

Een HelloRetryRequest voegt een rondlooptijd toe wanneer de server een andere sleutelwaarde nodig heeft. Gezamenlijke ondersteuning van een groep is niet voldoende als het eerste aanbod geen aanvaardbare waarde bevatte.

Bind de onderhandeling en scheid geheimen

Als Trudy onderweg sterke combinaties van versleutelingsalgoritmen uit een ClientHello verwijdert, leggen de client en de server verschillende versies van de uitgewisselde berichten vast. Authenticatie van die berichten mislukt. TLS bevat ook signalering van een versiedowngrade wanneer een geschikte server een oudere versie overeenkomt.

Het sleutelafleidingsschema gebruikt HKDF, gebaseerd op HMAC, om geheimen voor specifieke doelen af te leiden. Handshakesleutels beschermen berichten voor het opzetten van de verbinding; applicatiesleutels beschermen latere gegevens. KeyUpdate vervangt verkeerssleutels voor applicatiegegevens tijdens een langdurige verbinding. TLS 1.3 heeft statisch RSA-sleuteltransport verwijderd: een RSA-certificaat kan een handshake nog steeds door ondertekening authenticeren, terwijl tijdelijke sleutelovereenkomst voorwaartse geheimhouding biedt.

Hervat zonder certificaatauthenticatie te herhalen

Na het opzetten kunnen de communicatiepartners met NewSessionTicket hervatting voorbereiden. Ze leiden een PSK voor hervatting af uit het hervattingsgeheim en de nonce van het ticket; de client biedt het ticket later aan als identificatie van de PSK en bewijst dat hij die PSK bezit. Hervatting kan een nieuwe Diffie–Hellman-uitwisseling bevatten voor voorwaartse geheimhouding.

0-RTT verstuurt vroege gegevens met de eerste berichtenreeks, maar die vroege gegevens kunnen worden herhaald. Gebruik dit alleen waar herhaling van een verzoek veilig is, nooit voor een onbeschermde herhaalbare betaling. De bescherming van de latere handshake maakt vroege gegevens niet met terugwerkende kracht bestand tegen herhaling.

Wederzijdse TLS voegt een aangevraagd clientcertificaat en bewijs van de bijbehorende privésleutel toe. Hybride postkwantumgroepen zoals X25519MLKEM768, gedefinieerd in RFC 10024, combineren X25519 en ML-KEM-768, zodat de geheimhouding standhoudt als ten minste één component veilig blijft.

Versleuteling is alleen nuttig als ze de bedoelde communicatiepartner bereikt. Een client moet de identiteit achter de sleutels valideren voordat hij gevoelige applicatiegegevens verstuurt.

Controleer de volledige identiteitsclaim

Een TLS-client controleert of de certificaatketen een rootcertificaat in zijn opslag van vertrouwensankers bereikt, of handtekeningen en geldigheidsperioden in orde zijn, of de gevraagde naam overeenkomt met het certificaat en of het certificaat TLS-serverauthenticatie toestaat. Waar de client intrekking controleert, moet ook die controle slagen. CertificateVerify toont vervolgens aan dat de bijbehorende privésleutel wordt bezeten.

Bij het vergelijken van namen gaat het om de host waarmee de client contact wilde maken, niet om een naam die de server na het verbinden voorstelt. Een certificaat voor *.example.com dekt www.example.com en mail.example.com. Het dekt noch example.com, noch a.b.example.com: de joker vervangt precies één label. Een volledig geldig certificaat voor het verkeerde domein slaagt nog steeds niet voor authenticatie.

Een client vraagt bijvoorbeeld shop.example.net op, maar ontvangt een vertrouwd, geldig certificaat voor *.example.com. De keten en datums kunnen in orde zijn; de naamcontrole mislukt. De client moet die verbinding afwijzen. Een certificaat is geen algemene toestemming voor de houder om zich als een willekeurige server voor te doen.

Begrijp een versleutelde onderschepping

Als certificaatverificatie is uitgeschakeld, kan Trudy TLS van de client beëindigen en een tweede TLS-verbinding naar de echte server maken. Beide verbindingen zijn versleuteld, maar Trudy heeft daartussen de klare tekst. Controleren op versleuteling zonder de communicatiepartner te controleren mist daarom de aanval. Laat certificaatvalidatie ingeschakeld en beschouw een mislukte identiteitscontrole als een mislukte verbinding.

Een TLS-inspectieproxy van een organisatie gebruikt bewust een verwante structuur. Beheerde apparaten vertrouwen het rootcertificaat van de organisatie, zodat de proxy certificaten kan uitgeven die ze accepteren. De proxy beëindigt de ene beveiligde verbinding en start een andere. Het pad van browser naar server heeft dan een extra vertrouwd eindpunt met toegang tot klare tekst.

Bescherm het eerste verzoek

Bij SSL-stripping houdt een aanvaller de kant van de gebruiker op HTTP terwijl hij de website via HTTPS benadert. Dit kan beginnen wanneer een browser een adres zonder protocol eerst via HTTP probeert. HSTS draagt een browser op om bij latere bezoeken HTTPS te gebruiken. Een vooraf ingestelde vermelding kan HTTPS al vóór het eerste bezoek afdwingen; een beleid dat pas na een geslaagd HTTPS-bezoek wordt geleerd, kan een eerder HTTP-verzoek niet met terugwerkende kracht beschermen.

Bepaal wat zichtbaar blijft

TLS 1.3 versleutelt het servercertificaat en de applicatie-inhoud, maar waarnemers zien nog steeds netwerkadressen, poorten, timing en recordgroottes. Gewone SNI in de ClientHello onthult de gevraagde servernaam. Encrypted Client Hello, gestandaardiseerd in RFC 9849, beschermt die naam wanneer het wordt toegepast. Een afzonderlijk onbeschermde DNS-opzoeking kan ook de bestemmingsnaam onthullen.

TLS beschermt gegevens tussen de eindpunten tijdens het transport. Het kan malware op de client, een gecompromitteerde server, onveilig opgeslagen gegevens of fouten in applicaties niet verhelpen. Ook kan het niet voorkomen dat pakketten worden verworpen. IPsec heeft een ander bereik: het past bescherming op de netwerklaag toe op geselecteerd IP-verkeer zonder dat elke applicatie TLS hoeft aan te roepen. Door beide te gebruiken kun je verschillende delen van dezelfde route beschermen.

IPsec past bescherming toe op de IP-laag, waar het TCP-, UDP- en ICMP-verkeer kan dekken zonder de bijbehorende applicaties aan te passen. De eindpunten kunnen afzonderlijke hosts zijn of gateways die hele netwerken verbinden.

Kies een protocol en modus

AH gebruikt IP-protocolnummer 51; ESP gebruikt 50. ESP is de gebruikelijke keuze voor modern VPN-verkeer. De bescherming van AH omvat adresvelden die NAT herschrijft, waardoor gewone adresvertaling niet verenigbaar is met de authenticatiecontrole. ESP authenticeert de buitenste IP-header niet.

In transportmodus bevindt de ESP-header zich tussen de oorspronkelijke IP-header en het transportsegment. Routers zien nog steeds de oorspronkelijke bron en bestemming. In tunnelmodus adresseert een nieuwe IP-header de twee tunneleindpunten en reist het oorspronkelijke IP-datagram binnenin mee. Bij versleutelde ESP-tunnelmodus kunnen buitenstaanders de adressen en transportpoorten van de oorspronkelijke hosts niet lezen, maar wel de gatewayadressen die nodig zijn voor het doorsturen. AH in tunnelmodus biedt nog steeds geen vertrouwelijkheid.

IPsec kan vertrouwelijkheid, integriteit, authenticatie van de oorsprong en bescherming tegen herhaling bieden. De feitelijke diensten hangen af van het protocol, de algoritmen en het beleid; de keuze voor AH biedt geen versleuteling alleen omdat AH tot IPsec behoort.

Houd toestandsgegevens bij in elke richting

Een beveiligingsassociatie, of SA, definieert één richting van beschermd verkeer. Ze bevat algoritmen, sleutels, de modus, eindpunten, de volgnummerstand, de toestand van het venster tegen herhaling en een levensduur. Een 32-bits beveiligingsparameterindex, of SPI, helpt de ontvanger de juiste SA te selecteren. Het is een identificatie, geen versleutelingssleutel, en kan openlijk in de ESP-header worden verstuurd.

Voor verkeer in twee richtingen zijn twee IPsec-SA's nodig. Een gateway op het hoofdkantoor die één vestiging en 50 laptops van reizende medewerkers bedient, heeft 51 communicatiepartners. Met één ESP-paar per partner zijn $2\times 51=102$ ESP-SA's nodig, plus één IKE-SA per partner voor beheer. Sleutelvernieuwing of afzonderlijke verkeersklassen kunnen meer SA's toevoegen; deze telling volgt het genoemde ontwerp met één paar.

Hoewel IP-doorsturen verbindingsloos is, worden deze cryptografische toestandsgegevens bij de beschermende eindpunten bijgehouden. Tussenliggende routers hoeven de sessiesleutels niet te kennen of de IPsec-SA bij te houden.

Onderscheid beleid van actieve beschermingstoestand

De beveiligingsbeleidsdatabase (SPD) vergelijkt verkeersselectoren zoals adressen, protocollen en poorten. De beslissing is om geselecteerd verkeer te beschermen, bescherming over te slaan of het verkeer te verwerpen. De beveiligingsassociatiedatabase (SAD) slaat de parameters en veranderende toestand van bestaande SA's op. Een ontvanger gebruikt de SPI van het pakket en relevante context om die toestand te vinden.

De SPD beantwoordt “Wat moet er met dit verkeer gebeuren?” De SAD beantwoordt “Welke bestaande sleutels en tellers voeren die bescherming uit?” Een VPN-beleid kan kantoorsubnetten beschermen terwijl verkeer naar een andere bestemming de bescherming omzeilt. Als IPsec is ingeschakeld, betekent dat niet dat elk pakket dat een host verstuurt een tunnel ingaat.

Een VPN tussen vestigingen verbindt twee netwerken via gateways; een VPN voor toegang op afstand verbindt het apparaat van een gebruiker met een gateway. Beide kapselen verkeer in zodat gewone internetrouters het tussen de beschermende eindpunten kunnen vervoeren.

Breng de associaties tot stand

IKEv2 zet sleutels en SA's op. IKE_SA_INIT wisselt voorstellen voor algoritmen, Diffie–Hellman-waarden en nonces uit. De resulterende sleutels beschermen IKE_AUTH, waarin communicatiepartners hun identiteit authenticeren en het eerste paar ESP-SA's maken. Met handtekeningen of een vooraf gedeelde sleutel kost dit normaal gesproken vier berichten in twee rondlooptijden. EAP-authenticatie kan IKE_AUTH-uitwisselingen toevoegen. Latere uitwisselingen maken meer SA's of vervangen sleutels die bijna verlopen.

IKE gebruikt aanvankelijk UDP-poort 500. Wanneer NAT wordt gedetecteerd, gebruiken IKE en in UDP ingekapseld ESP poort 4500. ESP zelf heeft geen TCP- of UDP-poorten; door inkapseling kunnen NAT-koppelingen op basis van poorten het betrouwbaar vervoeren, ook voor meerdere clients. Het buitenste transport verandert, terwijl ESP het binnenste verkeer blijft beschermen.

Verstuur één datagram

Host 10.1.0.5 stuurt naar 10.2.0.9. De gateway van de vestiging is 198.51.100.1; het hoofdkantoor gebruikt 203.0.113.1.

1. De SPD van de vestiging selecteert tunnelbescherming voor het bestemmingssubnet en de gateway verkrijgt de bijbehorende SA.
2. De gateway behandelt het volledige oorspronkelijke datagram als de binnenste nettolading van ESP en voegt een trailer toe met opvulling, opvullengte en volgende header 4 voor IPv4.
3. De gateway versleutelt het binnenste datagram en de trailer en voegt de ESP-header toe met de SPI en het volgende volgnummer. Integriteitsbescherming dekt de ESP-header en de beschermde nettolading; een AEAD-algoritme integreert versleuteling en het maken van de tag.
4. De gateway voegt de buitenste IP-header toe, geadresseerd van de gateway van de vestiging naar die van het hoofdkantoor. Rechtstreeks ESP gebruikt protocol 50; NAT-doorgang vervoert ESP binnen UDP.

Internetrouters zien de buitenste eindpuntadressen. De interne adressen en poorten bevinden zich in de versleutelde nettolading.

Ontvang en authenticeer

Het hoofdkantoor gebruikt de SPI om een SA te selecteren, controleert het volgnummer voorlopig, verifieert de integriteit en ontsleutelt. Het werkt de vertrouwde toestand voor bescherming tegen herhaling pas bij nadat de authenticatie is geslaagd. Het verwijdert de tunnelbescherming en stuurt het teruggewonnen oorspronkelijke datagram door naar 10.2.0.9. Het veld voor de volgende header identificeert de teruggewonnen nettolading: 4 voor IPv4, 41 voor IPv6 of 6 voor TCP in een voorbeeld met ESP-transportmodus.

Sta herordening toe, maar wijs herhaling af

Een venster tegen herhalingsaanvallen van 64 pakketten met het hoogste geauthenticeerde nummer 1000 loopt van 937 tot en met 1000. Het nog niet eerder ontvangen pakket 990 kan laat aankomen en worden geaccepteerd. Een volgend exemplaar wordt afgewezen. Pakket 930 is te oud. Een geldig pakket 1005 verschuift het bereik naar 942 tot en met 1005. Een aanvaller kan het vertrouwde venster niet verschuiven door alleen een niet-geauthenticeerd pakket met een hoog nummer te versturen.

Een VPN beschermt alleen het pad tussen de eindpunten. Na verwijdering van de tunnel heeft interne aflevering waar nodig eigen bescherming nodig. Gesplitste tunneling stuurt een deel van het verkeer buiten de VPN om. Bij een commerciële VPN wordt de aanbieder een extra vertrouwde netwerkbeheerder. VPN's op basis van TLS/DTLS en WireGuard gebruiken andere protocollen om tunnels te realiseren; “VPN” benoemt de netwerkopzet, niet één verplicht versleutelingsprotocol.

Een wififrame is beschikbaar voor radioapparaten binnen bereik. Een aanvaller in de buurt kan verkeer onderscheppen of een nagebootst toegangspunt aanbieden: een vals toegangspunt met een bekende netwerknaam. Draadloze beveiliging moet toegang authenticeren en frames beschermen, niet alleen de netwerknaam verbergen.

Waarom WEP tekortschoot

WEP combineerde een gedeeld geheim van 40 of 104 bits met een openbare IV van 24 bits om RC4 te initialiseren. De CRC-32-controle detecteerde fouten, maar was geen authenticatiemechanisme met een sleutel. De IV-ruimte heeft slechts $2^{24}=\mathrm{16.777.216}$ mogelijkheden; bij willekeurig gekozen IV's is er na ongeveer 4.823 frames circa 50% kans op herhaling.

Een herhaalde IV met dezelfde sleutel herhaalt de sleutelstroom. Als je XOR op twee cijferteksten toepast, krijg je de XOR van de klare teksten. Door de lineaire structuur van CRC-32 kan een aanvaller ook bits wijzigen en de foutcontrole aanpassen. Een zwakke sleutelplanning van RC4 maakte het mogelijk de sleutel uit onderschepte frames te achterhalen. Deze problemen betreffen hergebruik van nonces, niet-geauthenticeerde integriteit en de constructie van het versleutelingsalgoritme; een minder voor de hand liggende netwerknaam kiezen verhelpt geen ervan.

Vervang de framebescherming

WPA2, gebaseerd op IEEE 802.11i, gebruikt CCMP: AES-versleuteling in tellermodus gecombineerd met CBC-MAC-integriteit. Het pakketnummer helpt unieke nonces te maken en herhaling af te wijzen. Het eerdere WPA/TKIP was een overgangsmaatregel voor oude hardware en wordt niet meer aanbevolen.

Een verbinding doorloopt detectie, authenticatie die een paarsgewijze hoofdsleutel (PMK) tot stand brengt, de vierweg-handshake en beschermde overdracht. In WPA2-Personal leveren een wachtwoordzin en netwerknaam een PMK van 256 bits op via PBKDF2 met 4.096 iteraties van HMAC-SHA1. Iedereen die die wachtwoordzin en SSID gebruikt, leidt dezelfde PMK af. De authenticatie heeft nog geen nieuwe verkeerssleutel per associatie opgeleverd.

Volg de vierweg-handshake

1. Het toegangspunt stuurt ANonce.
2. Het station genereert SNonce en leidt de PTK af uit de PMK, beide nonces en beide MAC-adressen. Het stuurt SNonce en een berichtintegriteitscode (MIC).
3. Het toegangspunt leidt dezelfde PTK af en controleert de MIC. Het levert de groepsverkeerssleutel (GTK) in een beschermd bericht.
4. Het station bevestigt de ontvangst en installatie.

De PMK wordt niet tijdens de handshake verstuurd. Nieuwe nonces leveren nieuwe sessiesleutels uit de bestaande PMK op. De GTK dient voor groepsverkeer, terwijl de paarsgewijze sleutel dient voor communicatie tussen dat station en het toegangspunt.

Weet wat het wachtwoord mogelijk maakt

Een onderschepte WPA2-Personal-handshake biedt een test om offline wachtwoorden te raden: leid een mogelijke PMK en PTK af, bereken de MIC opnieuw en vergelijk die met de onderschepte waarde. Een gebruiker die de wachtwoordzin van het netwerk al kent, kan ook de PTK van een andere gebruiker afleiden uit de onderschepte handshake van die gebruiker. KRACK maakte misbruik van herinstallatie van sleutels en hergebruik van nonces in implementaties; beveiligingsupdates verhelpen dat probleem.

WPA2-Enterprise gebruikt 802.1X. Het station is de aanvrager; het toegangspunt is de authenticator en stuurt EAP door naar een authenticatieserver, meestal via RADIUS. EAP-TLS gebruikt clientcertificaten; PEAP en EAP-TTLS vervoeren inloggegevens binnen TLS-bescherming. Gebruikers krijgen afzonderlijk sleutelmateriaal en hun toegang kan afzonderlijk worden ingetrokken. In beide modi eindigt wifibescherming bij het toegangspunt; TLS kan de bescherming tot aan een applicatieserver voortzetten.

Een beschermde draadloze verbinding heeft een deugdelijke manier nodig om sleutels tot stand te brengen. WPA3 verandert de manier waarop met een wachtwoord wifisleutels tot stand komen, terwijl mobiele netwerken beginnen met een abonneegeheim dat de simkaart en het thuisnetwerk bezitten.

Verbeter wifi op basis van wachtwoorden

WPA3-Personal gebruikt SAE om de PMK tot stand te brengen. Een onderschepte SAE-uitwisseling biedt geen offline wachtwoordtest zoals bij WPA2: elke poging vereist actieve interactie. SAE biedt ook voorwaartse geheimhouding, zodat het later achterhalen van het wachtwoord opgenomen eerdere sessies niet blootlegt. De vierweg-handshake leidt vervolgens verkeerssleutels af uit de PMK.

WPA3 vereist beschermde beheerframes (PMF), die robuuste beheerframes zoals deauthenticatieberichten authenticeren. Dit blokkeert vervalste berichten voor het verbreken van verbindingen; het kan radiostoring niet tegenhouden. WPA3-Enterprise behoudt 802.1X en biedt een optionele beveiligingsmodus van 192 bits met sterkere algoritmen zoals GCMP-256.

De overgangsmodus accepteert WPA2 en WPA3 onder één netwerknaam. Die compatibiliteit kan apparaten blootstellen aan de zwakkere WPA2-route. Bij gebruik van 6 GHz is WPA3 of Enhanced Open vereist en is de WPA2-overgangsmodus niet toegestaan; WPA3-Personal gebruikt de hash-to-elementmethode van SAE.

Enhanced Open, gebaseerd op OWE, brengt via Diffie–Hellman versleuteling zonder wachtwoord tot stand. Het voorkomt dat passieve afluisteraars frames lezen, maar authenticeert de hotspot niet. Een nagebootst toegangspunt kan een eigen versleutelde verbinding met de gebruiker opzetten.

Authenticeer een abonnee van een mobiel netwerk

Een lang gebruikt geheim $K$ bevindt zich in de USIM en de authenticatie-infrastructuur van het thuisnetwerk: HSS in 4G en UDM/ARPF in 5G. Een bezocht netwerk ontvangt authenticatiemateriaal zonder dat lang gebruikte geheim te kennen.

Bij 4G AKA verkrijgt de MME van het bezochte netwerk een vector met RAND, AUTN, XRES en sleutelmateriaal van de HSS van het thuisnetwerk. De telefoon ontvangt de willekeurige uitdaging RAND en het authenticatietoken AUTN. De USIM controleert AUTN om het netwerk te authenticeren en te controleren of de uitdaging nieuw is en berekent vervolgens RES. Het bezochte netwerk accepteert de abonnee wanneer RES overeenkomt met XRES. Afgeleide sleutels beschermen latere communicatie.

Dit is wederzijdse authenticatie. Het eerdere 2G GSM authenticeerde de telefoon bij het netwerk, maar gaf de telefoon geen gelijkwaardige controle van het netwerk, waardoor aanvallen met valse basisstations mogelijk waren. Wederzijdse authenticatie vereist nog steeds veilige algoritmen en correcte omgang met sleutels; het lang gebruikte geheim hoeft nooit naar het bezochte netwerk te worden gestuurd.

Verhul de permanente identiteit

In 5G neemt het thuisnetwerk de definitieve beslissing over authenticatie. De telefoon kan ook het abonneespecifieke deel van de permanente identiteit, SUPI, verhullen met de publieke sleutel van het thuisnetwerk om SUCI te vormen. Routeringsinformatie blijft leesbaar zodat het verzoek het juiste thuisnetwerk kan bereiken.

Verhulling vereist een ingesteld beschermingsschema. Het nulschema laat de identiteit onbeschermd. Beschermde SUCI vermindert de blootstelling aan apparaten die om permanente identiteiten vragen; ze maakt niet alle radioactiviteit anoniem. Na registratie verminderen tijdelijke identificaties het gewone gebruik van de permanente identiteit. Beveiliging van mobiele toegang beschermt nog steeds niet de volledige route naar een appserver: TLS biedt die afzonderlijke bescherming tussen applicatie-eindpunten.

Een firewall handhaaft beleid tussen netwerken of netwerksegmenten. Hij werkt alleen wanneer het relevante verkeer erdoorheen gaat en moet zelf bestand zijn tegen compromittering. Een toestandsloos filter neemt voor elk pakket opnieuw een beslissing op basis van headervelden.

Lees een regel nauwkeurig

Een regel kan overeenkomen met bron- en bestemmings-IP-adressen, transportprotocol, poorten, TCP-vlaggen, ICMP-type, interface en richting. Regels worden op volgorde beoordeeld: de eerste overeenkomst beslist. Een laatste regel voor standaard weigeren verwerpt pakketten die met geen toestemmingsregel overeenkomen.

Neem voor netwerk 203.0.113.0/24 een webserver op 203.0.113.10:

Een SYN van 198.51.100.7:50000 naar poort 443 van de webserver komt overeen met regel 1. Een SYN naar poort 22 bereikt regel 3 en wordt verworpen. Een antwoord van poort 443 van de server met ACK ingesteld komt overeen met regel 2. Elk veld in een regel telt: een pakket dat UDP-poort 443 gebruikt, komt niet overeen met een toestemmingsregel voor TCP.

Zoek regels die worden overschaduwd

Stel dat een eerdere regel zegt “sta inkomend TCP toe naar elke host in 203.0.113.0/24 op elke poort”. Een latere regel die SSH naar 203.0.113.10 weigert, heeft geen effect: de eerdere brede toestemmingsregel heeft al beslist. Controleer zowel de regelvolgorde als de formulering van elke regel. Zet bedoelde uitzonderingen vóór de algemene regel die er anders mee zou overeenkomen.

Standaard weigeren is nuttig omdat een nieuwe dienst niet ongemerkt bereikbaar wordt. Standaard toestaan heeft het tegenovergestelde gevolg: al het verkeer dat niet uitdrukkelijk is geblokkeerd, passeert. Geen van beide standaardkeuzes corrigeert een verkeerd geordende regeltabel.

Herken de verkorte ACK-controle

Een beleid kan inkomende SYN-pakketten met ACK niet ingesteld blokkeren om nieuwe TCP-verbindingen van buitenaf te stoppen. Om antwoorden aan interne clients toe te staan, kan een toestandsloos filter inkomend TCP van bronpoort 443 toelaten wanneer ACK is ingesteld. Trudy kan zowel die bronpoort als die vlag instellen. Het filter heeft geen geheugen dat bewijst dat een interne host de verbinding daadwerkelijk heeft geopend.

Een TCP ACK-vlag is een veld dat de zender kiest, geen bewijs van een tot stand gebrachte sessie. Toestandsafhankelijke filtering verbetert deze beslissing door de verbindingsgeschiedenis te raadplegen.

Filter vervalste adressen

Filtering van inkomend verkeer kan pakketten van het internet afwijzen die een intern bronadres of een privéadres opgeven dat daar niet hoort binnen te komen. Filtering van uitgaand verkeer wijst uitgaande pakketten af waarvan de bron buiten de aan de organisatie toegewezen bereiken ligt. Deze controles beperken vervalsing van niet-toegestane bereiken; ze identificeren geen afzonderlijke host en verhinderen niet dat een machine zich voordoet als een ander toegestaan intern adres.

Toestandsloze filters inspecteren headers, niet de betekenis van de applicatiegegevens. Poort 443 bewijst niet dat verkeer HTTPS of onschadelijk is. Een toegestane verbinding kan kwaadaardige inhoud vervoeren. Pakketfiltering werkt daarom samen met applicatiegateways, beveiliging op eindpunten en inbraakdetectie.

Een toestandsafhankelijke firewall voegt context toe aan pakketfiltering. Een applicatiegateway voegt inzicht in de verzoeken van één applicatie toe. Netwerkscheiding beperkt welke delen van het netwerk een gecompromitteerde openbare server kan bereiken.

Volg de werkelijke verkeersstroom

Een toestandsafhankelijk pakketfilter legt adressen, poorten, protocol en verbindingstoestand vast. Wanneer een interne client een toegestane verbinding opent, maakt de firewall een tabelregel aan en laat hij passende terugkerende pakketten toe. Een nieuwe inkomende verbinding heeft nog steeds eigen uitdrukkelijke toestemming nodig. Tabelregels vervallen wanneer de verbinding wordt gesloten of inactief wordt.

Stel dat de tabel een tot stand gebrachte TCP-stroom van 203.0.113.25:51000 naar 198.51.100.80:443 bevat. Een inkomend segment met dat adres- en poortpaar in omgekeerde richting kan overeenkomen met de vastgelegde toestand. Een ACK van 192.0.2.66:443 naar 203.0.113.30:52000 komt niet overeen met de tabelregel. De bronpoort en ACK-vlag zouden voldoen aan een ruime toestandsloze antwoordregel, maar bewijzen niet dat het pakket bij de bijgehouden verbinding hoort.

UDP heeft geen verbindingsopbouw zoals TCP. Toestandsafhankelijke filters benaderen een gesprek door recent gebruikte adres- en poortparen met een time-out bij te houden. Een DNS-verzoek aan een gekozen server opent tijdelijk de mogelijkheid voor het bijbehorende antwoord, maar geeft geen toestemming voor elk pakket dat beweert DNS te zijn.

Inspecteer het applicatieverzoek

Een applicatiegateway, of proxy, ontvangt en verwerkt namens gebruikers applicatieverkeer. Een webproxy kan een gebruiker authenticeren en een opgevraagd adres of opgevraagde inhoud aan het beleid toetsen. Om dat pad af te dwingen moet het pakketfilter voorkomen dat clients directe verbindingen openen die de proxy omzeilen.

Een proxy heeft protocolspecifieke logica, brengt verwerkingskosten met zich mee en kan een knelpunt worden. Clients moeten mogelijk worden ingesteld, of het netwerk kan verkeer transparant onderscheppen. Versleutelde inhoud blijft verborgen voor een proxy tenzij die de TLS-verbinding beëindigt en een nieuwe verbinding verderop maakt. Daardoor verandert welke eindpunten met klare tekst worden vertrouwd.

Isoleer openbare servers

Een DMZ is een afzonderlijk segment voor openbare diensten. De firewall staat geselecteerd verkeer van het internet naar de DMZ toe en beperkt de toegang van de DMZ tot het interne netwerk. Als een webserver wordt gecompromitteerd, krijgt de aanvaller niet automatisch onbeperkte interne toegang. Voor elke noodzakelijke verbinding van de DMZ naar het interne netwerk moet specifiek beleid gelden.

Dit is gelaagde beveiliging: meerdere maatregelen beperken verschillende manieren waarop beveiliging kan falen. Een hostfirewall blijft van belang als een geïnfecteerde laptop zich al binnen het netwerk bevindt of een andere verbinding de netwerkgrens omzeilt. Een zero-trustontwerp verleent geen toegang alleen omdat een apparaat zich op een intern subnet bevindt; het authenticeert en autoriseert verzoeken. De netwerklocatie kan meewegen in het beleid, maar kan identiteits- en toestemmingscontroles niet vervangen.

Een firewall kan een verbinding toestaan die een aanval bevat. Inbraakdetectie onderzoekt verkeersinhoud en patronen op tekenen van misbruik; inbraakpreventie kan direct op die bevindingen reageren.

Kies detectie en plaatsing

Een IDS observeert meestal gekopieerd verkeer en geeft meldingen. Een IPS staat direct in het verkeerspad en kan verdacht verkeer verwerpen. Die plaatsing maakt directe blokkering mogelijk, maar voegt verwerkingsvertraging toe en kan bij een onjuiste detectie legitiem gebruik onderbreken.

Snort en Suricata zijn voorbeelden van systemen die met handtekeningen kunnen werken. Een regel kan het verzoekpad ../../etc/passwd herkennen, meer dan 20 nieuwe verbindingen naar SSH-poort 22 vanaf één bron binnen een minuut, of SYN's naar honderden poorten. Deze patronen wijzen op verdacht gedrag; een overeenkomst alleen bewijst geen geslaagde inbraak.

Een anomaliedetector kan een grote verandering in verkeerssnelheid of protocolmix markeren. Een nieuwe legitieme back-uptaak kan er ook ongebruikelijk uitzien. Een foutpositief is een melding over onschadelijke activiteit; een foutnegatief is een aanval die de detector mist. Een gevoeligheidsdrempel verschuiven betekent meestal dat de ene soort fout wordt ingeruild voor de andere.

Bereken wat een melding betekent

Neem 1.000.000 onschadelijke verbindingen en 10 aanvallen per dag. Een detector vindt 99% van de aanvallen en geeft ten onrechte een melding bij 0,1% van de onschadelijke verbindingen.

1. Verwachte terechte meldingen: $10\times \mathrm{0,99}=\mathrm{9,9}$.
2. Verwachte valse meldingen: $\mathrm{1.000.000}\times \mathrm{0,001}=1.000$.
3. Verwacht aandeel terechte meldingen: $\mathrm{9,9}\mathrm{/}(\mathrm{9,9}+1.000)\approx \mathrm{0,0098}$, oftewel ongeveer 1%.

Dit zijn verwachte aantallen over meerdere dagen, dus 9,9 hoeft geen geheel aantal meldingen op één dag te zijn. Het detectiepercentage van 99% is het aandeel gedetecteerde aanvallen, niet de kans dat een melding een aanval betreft. Zeldzame aanvallen en een enorme hoeveelheid onschadelijke verbindingen verklaren het verschil: dit is het probleem van de basisfrequentie.

Plaats sensoren waar ze kunnen waarnemen

Sensoren direct achter de firewall observeren verkeer dat de firewall is gepasseerd. DMZ-sensoren observeren verkeer naar openbare diensten; interne sensoren kunnen aanvallen onthullen die nooit de netwerkgrens passeren. Een sensor moet het ontvangen verkeer kunnen bijhouden. Hij moet ook fragmenten en TCP-segmenten op dezelfde manier als het doel weer samenstellen; anders kan een over pakketten verdeelde aanval aan een patrooncontrole ontsnappen.

TLS en IPsec verbergen versleutelde nettoladingen voor een netwerksensor die geen toegang heeft tot ontsleuteling. Adressen, poorten, timing, lengtes en onversleutelde handshakevelden kunnen nog steeds helpen. Inspectie van nettoladingen kan plaatsvinden op een eindpunt waar ontsleuteling plaatsvindt, maar een gewone gekopieerde versleutelde stroom levert die klare tekst niet op.

Een honeypot is een loksysteem zonder bedoelde gewone gebruikers. Contact is daarom verdacht en kan scan- of aanvalstechnieken zichtbaar maken met minder achtergrondruis. Verkeerd ingestelde clients of onschadelijk geautomatiseerd verkeer kunnen er nog steeds contact mee maken, dus een loksysteem maakt niet elke melding doorslaggevend.