Door majortom: ITSME gebruikt volgens mij cryptografische bescherming waarmee, wanneer zowel client als service de goede checks uitvoeren, eea op die manier gegarandeerd moeten zijn waarmee dat voorzetscherm (a la MitM) zou moeten worden voorkomen.
De automaat is, voor de paspoort-afhaler, een
server die noodzakelijkerwijs door de afhaler zal moeten worden vertrouwd (zie ook -lang-
https://infosec.exchange/@ErikvanStraten/113031344934186250 - een write-up die ik mogelijk binnenkort op deze site publiceer).
In hoeverre vormt de fysieke locatie van zo'n automaat een bewijs van diens authenticiteit (echtheid) en integriteit?Aanvulling 12:39: {
Hoeveel zouden de risico's, in de eerste plaats voor burgers, worden verlaagd indien dat soort automaten
uitsluitend binnen gemeentehuizen zouden worden geplaatst,
én burgers er pro-actief + uitdrukkelijk voor zouden worden gewaarschuwd om
nooit zo'n automaat
buiten een gemeentehuis te vertrouwen? (Hoeveel weegt 24x7 op tegen het grotere risico?)
}
M.a.w. hoe moeilijk is het voor aanvallers om ergens een identiek lijkende automaat te plaatsen? Eentje die, als AitM - in combinatie met een oplichter die voor de
echte automaat staat waar het paspoort uitrolt, te laten fungeren?
Oftewel, hoe sterk is de authenticatie (plaatsvindend zonder dat de meeste mensen zich dit, en het belang daarvan, realiseren) indien impersonatie (van de automaat) eenvoudiger is dan wordt gesuggereerd?
Ik kan het niet bewijzen, maar dat AitM's onmogelijk zouden zijn, geloof ik simpelweg niet. Het bewijst niks maar is wel een aanwijzing: in het scherm op de foto van de automaat zie ik een QR-code met een lage resolutie.
Probleem: AitM
Nb. Ik probeer dit voor elke lezer begrijpelijk te maken.
"AitM" staat voor Attacker in the Middle (ook bekend als MitM, de eerste 'M' voor "Man").
In essentie wordt, bij een AitM-aanval, informatie tussen twee eindpunten ongeautoriseerd (zonder toestemming, met kwaadaardige bedoelingen) "ergens onderweg" afgeluisterd, en/of (deels) gewijzigd, en/of geheel vervangen of (deels) geblokkeerd.
AitM aanval gevisualiseerd
Vaak vinden AitM-aanvallen plaats middels
impersonatie, waarbij de aanvaller zich richting één van de, of zelfs beide, partijen voordoet als de andere partij:
Veilig gewaand communicatiekanaal
| |
v v
o <••••••••••• AitM •••••••••••> o
/|\ "Ik ben / \ "Ik ben /|\
/ \ partij 2" partij 1" / \
Partij 1 Partij 2
Als partij 1 de paspoortafhaler is, dan is partij 2 in bovenstaand "plaatje" de uiteindelijk verantwoordelijke voor het authenticatiesysteem.
Altijd ketens - met soms onverwacht véél schakels
AitM aanvallen kunnen, in principe,
overal tussen de feitelijke eindpunten plaatsvinden (op elk "thing" in "Internet of Things"), zelfs
binnen het door één van de eindpunten gebruikte apparaat (zoals een smartphone of een PC):
Veilig gewaand communicatiekanaal
| |
v v
o <••[IoT]•[IoT]••[IoT]•[IoT]••> o
/|\ /|\
/ \ / \
Partij 1 Partij 2
(In mijn definitie is een IoT een apparaat met minstens één netwerkaansluiting (kan ook draadloos) en minstens één IP-adres. Nb. Ik ga niet reageren op commentaar hierop).
AitM technisch onmogelijk maken
Men
kan een AitM
tussen twee of meer IoT's (uitgezonderd de eindpunten zelf!) in de praktijk onmogelijk maken, in elk geval door gebruik te maken van TLS (en dus ook https). Doch
uitsluitend indien aan een aantal essentiële voorwaarden wordt voldaan, waaronder:
1) Betrouwbare server-authenticatieDe server (aan het einde van het kanaal) bewijst naar de client dat hij is wie hij claimt te zijn, meestal op basis van een door een derde partij uitgegeven servercertificaat, gecombineerd met het (elke sessie opnieuw) bewijzen van het bezit van een private key (passend bij de public key in het certificaat, en zonder die private key zelf ooit prijs te geven);
2) E2EE (End-to-End-Encryption)Er komt een versleutelde verbinding tot stand vanuit de client richting de server en vice versa (dit sluit een AitM "onderweg" nog niet uit);
3) Bewijs van géén AitM "onderweg"De client en de server genereren, vereenvoudigd, zeer grote random getallen die, aanvankelijk, alleen
zij kunnen kennen. Vervolgens en wisselen zij deze (of afgeleiden daarvan) -asymmetrisch versleuteld- met elkaar uit en bewijzen daarmee aan elkaar dat
zij die getallen hebben gegenereerd. Dit is nogal technisch, zie ietsje verderop voor een vereenvoudigde toelichting;
4) De client authenticeertNadat de (gebruiker van de) client zeker weet dat er een
niet-afluisterbare én niet-wijzigbare verbinding met de bedoelde server bestaat, authenticeert de client ("logt in") waardoor de server weet dat de client is wie deze claimt te zijn.
Nb. de eerste twee stappen worden omgewisseld sinds TLS v1.3.
Waarom stap 3 AitM's voorkómt
De kracht zit hem in stap 3. Ter vergelijking, indien telefoonnummers niet gespoofd (vervalst) zouden kunnen worden, zou je dit mechanisme kunnen vergelijken met dat beide bellers elkaars telefoonnummer in het scherm van hun telefoons zien, en dat elk van hen exact weet van wie het in hun telefoonscherm getoonde nummer "van de andere kant" is (en dat de verbinding,
End-to-End, versleuteld zou zijn).
Stap 3 is in de praktijk onmogelijk zonder betrouwbare asymmetrische cryptografie, waarbij zulke grote getallen moeten worden uitgewisseld dat het "verkeer" nauwelijks of niet in een QR-code past, laat staan door mensen (foutloos) kan worden "overgetikt".
Meer data kunnen uitwisselen
Denkbaar is wel dat de afhaler, met diens smartphone, een draadloze verbinding moet opzetten met een zend/ontvanger (radiogolven) in de automaat.
Maar dat leidt weer tot een nieuw probleem: hoe weet je zeker dat jouw smartphone met de
bedoelde transceiver (zend/ontvanger) in de automaat communiceert?
Dat is in elk geval een risico als er nog niet opgeloste (of bij de leverancier nog onbekende bugs in "hun systeem" zitten), maar hoeft niet persé te betekenen dat een AitM-aanval op ItsMe dan mogelijk is. Immers, er kan een TLS-tunnel tussen de ItsMe app op jouw smartphone en de ItsMe-server zijn opgezet. Echter, alle interactie met het scherm van de automaat kan dan géén gebruikmaken van die tunnel.
Dus: welke informatie precies wordt er met de automaat zelf uitgewisseld als deze niet gehacked is, en, indien de automaat
wél gecompromitteerd is, welke informatie
zou er dan met de afhaler kunnen worden uitgewisseld zodanig dat die afhaler op het verkeerde been wordt gezet en/of waardedocumenten aan een bedrieger worden uitgegeven?
Los daarvan loop je sowieso risico's als je verbinding maakt met een potentieel ongetrouwbaar "access point" (denk o.a. aan kwetsbaarheden in de Bluetooth, NFC of WiFi chipset(s)/firmware in jouw smartphone, of pogingen van apps op jouw smartphone om via zo'n verbinding op onveilige wijze updates te downloaden).
In die pagina viel mij meteen het volgende op:
Alleen jij kent je code
Er bestaat geen databank van itsme®-codes. Je bent dus de enige persoon in de wereld die de 5-cijferige code kent om je itsme®-app te gebruiken.
Dat laatste is op z'n minst suggestief onjuist. Niet alleen jij moet de pincode kennen, de app moet dat ook (*).
(*) Of een één-weg afgeleide daarvan, maar die is altijd te reversen - doordat een 5-cijferige code slechts 100.000 mogelijke cijfercombinaties kent(en wellicht minder, zie "
De verboden reeksen van Satya Nadella" in
https://security.nl/posting/853298).
Leugentjes om bestwil? Wat is er nog meer gewoon niet waar?
Door majortom: Wat betreft het issue: is het de juiste persoon die het ID bewijs afhaalt, gaat men (ik denk ten onrechte) uit (zoals al dit soort systemen doen) dat degene die de telefoon gebruikt ook altijd de eigenaar is en dat die persoon de telefoon niet uitleent (ik ken genoeg mensen die samen doen met 1 telefoon), deze niet is gecompromitteerd etc (alsof het een onlosmakelijk verlengstuk van jezelf is). Daar gaan al dit soort systemen mank. Goede identificatie van de persoon is gewoon op al dit soort manieren niet mogelijk, het is altijd te compromitteren.
Exact! AitM "malware" (zoals AnyDesk) op jouw smartphone en niks helpt nog.