Ik zou een router geen IoT-apparaat noemen. Het is geen koelkast die zo nodig internetverbinding nodig heeft, het is de router waarmee je thuisnetwerk met het internet verbonden is.

En hoe je zoiets doet? Zo'n apparaat kan een self-signed certificaat genereren. Daarvoor krijg je dan een waarschuwing in je webbrowser, maar je kan het certificaat als uitzondering toevoegen en dan werkt het. Wel blijft de browser aangeven dat de site onveilig is. Naar mijn mening is dat ten onrechte, ik zou liever een aparte status zien voor self-signed certificaten waar je die uitzonderingen voor hebt gemaakt, maar dat is hoe de browsers nu werken.

Ik stel voor om niet te discussiëren over wat precies wel en niet een IoT device is (noch over full disclosure, besturingssystemen, open/closed source en dergelijke). Het gaat mij niet om client devices (zoals PC's, smartphones maar ook bijvoorbeeld afstandsbedieningen) voor zover deze verbindingen initiëren.

Het gaat mij om special purpose apparaten, met server-functionaliteit voor beheertaken en/of het uitwisselen van gegevens. Dus waar je, vaak gebruik makend van een wachtwoord (of client certificaat) op inlogt om iets te doen. Voor dat soort devices, die velen steeds meer om zich heen verzamelen, lijkt "out of the box" geen goede authenticatiemethode te bestaan (van de server, bedoel ik). Waardoor je, als je inlogt, geen idee hebt aan wie of wat je jouw inloggegevens toevertrouwt.

Dan is de titel slecht gekozen en ook je initiële vraag waar je IoT benadrukt onhandig. Je probleem is de stelling dat een apparaat een 'proxy'-achtige dienstverlening gebruikt en dat daar risico's aanhangen. Dat is niet nieuw en zeker niet uniek voor IoT apparaten.
Man-in-the-middle anyone?

Conclusie: wat is nu precies je vraag? Begrijp je het zelf wel?

De aanpak van Netgear, met twee publiek uitgegeven certificaten (die ondertussen vermoedelijk allebei zijn ingetrokken) is natuurlijk niet de juiste methode om de authenticiteit van een IoT device of netwerkapparaat (router, switch, NAS etc.) te waarborgen (noodzakelijk vóórdat het zin heeft om over versleutelde verbindingen te praten).

De vraag is: wat is de beste aanpak, gegeven dat webbrouwsers steeds moeilijker doen over http? Of zouden juist makers van webbrowsers hun product hierop moeten aanpassen - maar tot welke risico's zou dat dan weer leiden?

Insgelijks.

Buzz, buzz, buzzword alert. Blockchain. Echt waar en meer (o.a. tampering protection): A Blockchain-Based Authentication and Security Mechanism for IoT --https://ieeexplore.ieee.org/document/8487449.

Hoe weet je of je de eerste node in een blockchain kunt vertrouwen?

D. Data integrity verification in the blockchain in het paper.

Ik denk niet dat je dit probleem met PKI kan oplossen. Dat kun je zien aan dat het gedram om https (en het is gedram) dit soort problemen oplevert. Want het model valt op het moment dat de serverkant niet als een server (in een datacentrum, met een beheerder) beheerd wordt, zoals hier het geval is. Alle beschikbare alternatieven binnen PKI stinken nog harder, om verschillende redenen. Je kan niet veel meer dan lobbyen bij browsermakers om niet te zeuren over "encryptie" bij lokale verbindingen, en zelfs daar zitten risicos aan.

Wil je het wel goed doen en tegelijkertijd geen tcpa/paladium/uefi-secure-boot of vergelijkbare lock-in, dan moet je iets heel nieuws verzinnen. Is me nu een beetje teveel werk om even uit de mouw te schudden, dus ik laat het nu maar even bij de conclusie dat dit de randen van het haalbare binnen PKI en dus ook https laat zien.

Dat gaat over latere blocks.

Je gaat altijd tegen het probleem aanlopen dat je het eerste block maar gewoon moet vertrouwen.

Deze procedure van Netgear slaat als een tang op een varken. Het is je reinste zeepbel van security.
Ik heb het artikel gelezen en het komt overeen met een geregistreerd sluitplan (sleutels & sloten) waarvoor om extra sleutels of sloten te verkrijgen het er niet toe doet of je deze bestelt met of zonder certificaat omdat het laatste in beide gevallen een totale wassen neus is!

Ik krijg de indruk dat je in dit wereldje - het software wereldje - van de ene verbazing in de andere tuimelt als nuchter niet software-nerd door een valide vergelijking te trekken van een software protocol naar de realiteit.

Die verbazing moet mij ook van het hart als ik de meer dan stompzinnige reactie hierboven lees waar feitelijk een enorme afgunst jegens TS zijn intellect de voedingsbron van is. (15:56 uur)

Ook hier geldt, degene die de verificatie procedure heeft uitgewerkt heeft er een bepaald vertrouwen in.
Degene die hem niet heeft uitgewerkt doorziet en overziet de procedure en werking ervan niet per sé in het geheel.
Je kan wel een herkenbare node als vertrekpunt nemen als je iets gaat distribueren,
als de distributie niet fysiek is maar digitaal dan heb je niet in de gaten of een geval van duplicaties / replicaties / verprutsingen zich juist wel of niet voordoet.
Je hebt het nog minder in de gaten doordat het digitale verkeer sneller en sneller wordt en meer en meer gegevens omvat.
Zie het digitale verkeer als het ware als elkaar snel opvolgende hooibergen waar je steeds pijlsnel de spel uit moet zoeken en controleren.
Iets dat je kan beet-pakken kan ieder willekeurig iemand in principe op authenticiteit beoordelen.
Het beet-pakken en beoordelen kan iemand beter reguleren dan wat er aan digitaal verkeer langs komt.
Een niet-fysiek iets kan niet door ieder willekeurig persoon op authenticiteit geverifieerd worden.
Je hebt er extra situatie gebonden kennis en inzichten voor nodig.
Ook al zijn er natuurlijk mensen die zich wel gerust gesteld kunnen voelen als de een sample dat als authentieke eerste node langs komt enigszins authentiek lijkt, dat maakt het nog niet per sé authentiek.

Een beetje geverifieerd kan wel, een beetje authentiek is echter een contradictie in termen.
Het blockchain verificatie idee is iets dat moet functioneren als een virtueel iets, en de mogelijkheden voor toepassing ervan zou je in tal van toepassingen kunnen overwegen.
Door inzet het virtuele karakter bij een breed publiek blijft het verificatie idee altijd een vrij beperkte integriteit uitkomst houden.
Hoe ingewikkeld en/of handig je dat verificatie idee ook inricht.

Ik lees dat dit juist de bedoeling is. Je hebt - startend vanuit latere nodes - een cryptografisch geborgd pad naar de root en als je er bent, na dat pad te hebben gevolgd, vergelijk je met wat je weet wat de root moet zijn.

@20:04 door Anoniem Heb je het paper wel gelezen? De crux is juist de cryptografische borging van het pad naar de root. De root 'vertrouw je' net zoals je 'security.nl' vertrouwt (het is echter heel wat gemakkelijker om die laatste te faken dan bij de eerste).

Paper TL;DR. Gezien jouw overtuiging dat blockchain de authenticatie van thuis-devices met server-functionaliteit en RFC1918 IP-adressen zou kunnen faciliteren, kun je kort en eenvoudig uitleggen hoe? Inclusief hoe dat out-of-the-box zou kunnen werken? (Want dat laatste is waar Netgear in probeerde te voorzien).

Nee, het paper zelf (dat kan je ophalen).


Hoezo 'mijn' overtuiging? Lees gewoon het paper.

Ok, ik heb het paper gedownload (uit https://www.researchgate.net/publication/328247073_A_Blockchain-Based_Authentication_and_Security_Mechanism_for_IoT waar je niet hoeft te betalen en PII te lekken. Als bonus staat er onderaan de pagina wat meer info dan op de IEEE site die jij noemde).

En ik heb het gescand. Maar zo te zien staat er niets in dat mijn oorsponkelijke vraag beantwoordt - zodat het bruikbaar is voor eindgebruikers:

@The FOSS: even googlen en iets over de schutting gooien is leuk, maar hoe stel jij je de implementatie voor?

P.S. Ik zie er ook zo snel geen handige oplossingen in, maar de PDF te downloaden vanuit https://www.mdpi.com/1424-8220/19/5/1141 lijkt de problematiek wel grondig te beschrijven. Wie weet kennen anderen vergelijkbare of betere bronnen?

Out of the box voor thuis-devices die niet gestaged worden door een 'echte' beheerder is een heel moeilijk probleem.

Als je begint met staging kun je van alles verzinnen op basis van een shared secret , waarbij de validatie dat je het juiste device enrollt is omdat dat het ding op je buro is waar je met de console kabel ingeprikt zit.
Je kunt bluetooth pairing (met die nummercode) ook zo beschouwen.
En natuurlijk het installeren van een eigen certificaat . Maar dat is allemaal niet "out of the box voor de home-user" .

Het beste dat ik kan verzinnen vergt een TPM chip waarin een door de vendor gesigned device certificaat zit met iets van het serienummer van het device .
Als de TPM chip zich waarmaakt, en de vendor z'n productieproces onder controle heeft kun je een heel stevige garantie krijgen/geven dat je verbinding maakt met een device met dat serienummer - als dat dan ook op het kastje staat wat je gekocht had ben je toch wel zeker dat je verbinding maakt , zonder MITM met _dat_ kastje .

Niet zo bruikbaar voor de standaard eindgebruiker - maar een op het apparaat geprinte SSH fingerprint (waarbij de key ook factory default , device-uniek en niet-retrievable moet zijn ) komt op hetzelfde neer.
Dit zijn allemaal dingen die afhangen van het hebben van een TPM achtige module waarbij de secrets niet gecloned kunnen worden .

Als je wilt werken 'on the fly' pairing zonder vooraf ingestelde device-unieke kenmerken heb je , denk ik, enige userinterface op het apparaat nodig - of moet je het fysiek aansluiten en dan de pairing van management client <-> device doen.
Dat is technisch wel voorstelbaar - maar je komt dan al heel snel op het terrein van 'management client' (die onder water gewoon een certificaat , of SSH authorized key instelt ) . Je verliest dan het gemak van 'werkt met iedere browser'. En je eist dat een eerste installatie met een fysieke lokale koppeling gedaan wordt.

Net iets minder secure - maar voor thuisgebruik typisch 'meer dan goed genoeg' zijn koppel-protocollen van het type "koppel met de eerste controller die je hoort op het lan gedurende 30 seconden na het indrukken van de koppel-knop-sequentie" .
Dat is wat Sonos boxen doen, en geen slechte keuze gegeven dat er op de client maar drie knoppen zitten en geen display.
(na power on een bepaalde knop ingedrukt houden, en dan koppelt de box zich aan een controller die op dat moment op het lan aanwezig is). Ook dat werkt met een client, niet met een browser. En bij Sonos niet echt cryptografisch goed, maar dat zou oplosbaar zijn zolang je uit mag gaan van het model "het lokale LAN bevat geen MITM op moment van enrollment" .

Hier bestaat tegenwoordig hele aardige hardware voor.
https://www.microchip.com/en/pressreleasepage/microchip-simplifies-hardware-based-iot-security-trust-platform.
Lijkt me prima spul. Ik dacht dat ik het al eens had doorgegeven op deze site.
Maar de redactie vond het zeker niet interessant genoeg om te plaatsen, of er gaat wel eens wat mis.

Deze heeft overigens ook authenticiteit aan boord (private key):
https://www.security.nl/posting/470065/Nieuwe+bouwsteen+voor+veilig+Internet+of+Things+%28IoT%29

Omdat het in de hardware zit ingebakken is de private key naar ik had begrepen nogal moeilijk te stelen door iemand die zich (via internet) op één of andere manier illegaal toegang weet te verschaffen tot het netwerk.

@Anoniem 13:27 hierboven: dank voor jouw serieuze reactie!

Ik had een uitgebreid antwoord geschreven (op m'n smartphone) toen ik, per ongeluk, op "privacy policy" drukte en alle tekst foetsie was :-( Ik probeer het morgen nog wel een keer.

voor wiens thuisgebruik?
typisch 'meer dan goed genoeg'? Omschrijf het "goed" dan uberhaupt eerst eens even.
Bedoel je praktisch genoeg?
Of moet het "goed genoeg" iets anders omvatten?
En wat m.b.t. "meer dan goed genoeg"?

Dan het volgende, pairen van apparaten ideeën m.b.t. druk op een pair knop.
pairing van 2 of meer apparaten middels een knop is een principe waarin doorgaans minimaal 2 tot meer signalen worden afgegeven door alle andere eventueel aanwezige apparaten waar het transmissie-signaal van aan staat.
Dat is simpel gezegd een "hier ben ik signaal".
Dan heb je bij het indrukken van de pairing knop minimaal een 2e signaal.
Alle apparaten scannen continu of ze het 2e signaal lang genoeg verwerken om met de zendende bron een informatie uitwisseling op te zetten.
Dat noem ik gemakshalve een "ik wil nu pairen signaal".

Wie of wat die signalen allemaal opvangt of ertoe - fysiek of digitaal - toegang toe heeft via andere apparaten heb je niet in de hand.
Enkel dat de mogelijkheid daartoe beperkt is tot slechts een paar voorwaarden.
Namelijk, 1)tot 1waar de transmissie reikt, 2) of het ontvangend apparaat binnen de transmissie bereik staat, 3)er geen verstoring in informatie uitwisseling is en dat het moment van een pairing niet op het laatste moment wordt meegelezen.
Dat laatste kan moedwillig door tal van mechanismen gebeuren.
Dat maakt het principe van pairing met draadloze signalen wezenlijk ANDERS qua security dan middels fysieke draadverbindingen toepassen.
Niet volledig in functionele zin, wel in technische zin. En dat is hierbij doorslaggevend.
Er zijn dan ook behoorlijk wat router fabrikanten en adviseurs die voor het opzetten van draadloze verbindingen aanraden om eerder een wachtwoord gebaseerde verbindingen toe te passen en dit in ieder geval niet op basis van knop-pairing te doen!
Pas dus in je processen enkel met breder inzicht en met je verstand erbij dan ook geen pairing toe op basis van een knop toe, of je het nou voor een bedrijf of particulier doet!
Voer je draadloze pairing uit tussen 2 apparaten waar je ook een kabel tussenin prikt, waarom dan in hemelsnaam die draadloze verbinding nog willen?
Zodra je de kabel er trouwens uit zou halen dan ben je sowieso de fysieke unieke identificatie kwijt, dan ben je technisch terug bij het rammelende verbinding gebruiken op basis van 1 knop maar zonder instelbaar wachtwoord.

Verder, het "lokale LAN bevat geen MITM op moment van enrollment"-idee is bij draadloze verbindingen om tal van reden sowieso niet je enige of grootste zorg van inbreken op een sessie.
Replicatie risico's zijn op talloze wijze mogelijk EN de apparaten die je wilt pairen weten NIET dat ze dat moeten stoppen omdat ze niet echt door kunnen hebben of ze worden geschaduwd. Dit zijn de principes en zijn van toepassing voordat en nadat elke knop-gepairde verbinding tot stand wordt gebracht.
De apparaten weten VOOR de pairing sessie start niet met welke signalen de authentieke of voorbestemde zijn.
Je kan dan wel met versleutel ideeen aankomen, maar de apparaten moeten eerst daarvoor onderscheid kunnen maken tussen de JUISTE en ONJUISTE apparaten.
En dan moeten die ook nog dezelfde combinaties pairing info met elkaar afstemmen, oftewel de enige voorbestemde pairing informatie tussen willekeurige apparaten kan NIET op een gedeeld signaal worden vastgesteld.
Je zou daarnaast moeten nagaan wat het mee-lezen van transmissies en/of signaal-informatie überhaupt voor mogelijkheden kan openen.

Het "TPM chip waarin een door de vendor gesigned device certificaat zit met iets van het serienummer van het device" is al iets dat in bluetooth apparaten op low-level techniek zit.
En bluetooth alliantie heeft bedacht dat een certificaat embedden in de chip niet voldoende garanties biedt.

Absoluut, vandaar dat ik deze draad gestart ben; ik ben benieuwd wat de huidige "best practice" is en wie weet hebben lezers goede ideeën!

Ik vrees dat veel IoT devices geen console kabel hebben. Je ontkomt dan niet aan de trucs die jij van Sonos beschreef, maar erg gelukkig word ik daar niet van.

Ik weet niets van BlueTooth (omdat ik het te onveilig vind en daarom niet gebruik, wellicht ben ik te paranoïde ;-)

Als je moet beginnen via WiFi (zonder "console kabel" dus), dan is de veiligheid verre van maximaal als je niet weet of je met het juiste device communiceert. Netgear probeerde voor dat laatste probleem een oplossing te bieden, maar dat is natuurlijk mislukt.

Persoonlijk zie ik de noodzaak voor een TPM chip niet zo: je moet het hele apparaat kunnen vertrouwen als je inlogt, niet alleen de private key.

Ik ben het met je eens dat er er iets ter verificatie op een sticker o.i.d. moet staan, d.w.z. ervan uitgaande dat elk device een uniek sleutelpaar en dus uniek (self-signed) certificaat beschikt. In elk geval moet de hash (AKA fingerprint) van het certificaat zijn afgedrukt! Dat sleutelpaar en certificaat moeten dus in de fabriek (bijv. bij eerste keer aanzetten) worden gegenegeerd.

Anders kan een MitM op het netwerk (ik denk niet alleen aan simpele thuisnetwerkjes) on-the-fly een nepcertificaat genereren waaraan de gebruiker niet kan zien of dat van het bedoelde apparaat afkomstig is. Daarmee heb je minder kans op collisions dan bij indentifiers als serienummer of MAC-adres (ik heb wel eens een HDD gehad met allemaal nullen als serienummer, en op de TU Delft had een andere vakrgoep dan waar ik werkte enorme problemen met via het netwerk ontsloten sensoren - totdat ze ontdekten dat die allemaal hetzelfde MAC-adres hadden).

Bij de eerste verbinding die je met jouw webbrowser maakt met het apparaat, kun je de hash controleren voordat je het certificaat door de browser laat opslaan. Daarnaast moet het mogelijk zijn om het apparaat zelf een nieuw sleutelpaar en certificaat te laten genereren (waarbij je de hash daarvan natuurlijk wel moet registreren, bijv. door deze op een sticker op het apparaat te schrijven en/of in je wachtwoordmanager op te slaan). Het is ook prettig als je zelf een certificaat plus private key kunt uploaden naar het device (om te voorkomen dat een slechte random number generator een voorspelbaar sleutelpaar maakt).

Helaas zijn hiermee een stel problemen nog niet opgelost.Netgear gaat/ging ervan uit dat je, door te surfen naar https://routerloging.net/ of https://routerlogin.com, verbinding met jouw router zou maken. Maar dat werkt alleen als die router ook jouw DNS provider is; zodra je van DoH (DNS over https) gebruik maakt, is dat niet meer het geval (iets waar de Netgear pagina, waar je op dit moment op uitlkomt als je geen Netgear router hebt of DoH gebruikt, kennelijk geen rekening mee houdt).

Maar ja, met DoH ingeschakeld zou ik ook niet meer naar https://fritz.box/ (met self signed certificate) kunnen surfen. En op mijn Android smartphone lukt dat ook niet eens betrouwbaar, want ik ontdekte (hierdoor) dat Android 8.8.8.8 als alternatieve DNS server heeft ingesteld; als die sneller antwoordt (wat soms gebeurt) dan mijn Fritx!Box router, kom ik niet bij de gebruikersinterface van mijn router.

Overigens heeft mijn Fritz!Box al meerdere keren, om mij onduidelijke redenen, een nieuw certificaat gegenereerd - waardoor ik (na zo'n wissel) natuurlijk een foutmelding in mijn browser krijg. Opmerkelijk daarbij is dat de public key wel steeds hetzelfde is, waardoor ik redelijk zeker weet dat ik nog met dezelfde Fritz!Box communiceer. Maar absurd vind ik dit wel (en aan de ene kant fijn dat het sleutelpaar niet vervangen wordt, aan de ander kant is dat vergelijkbaar met je wachtwoord wijzigen in ... hetzelfde wachtwoord.

Daarnaast, hartstikke link eigenlijk dit soort DNS trucs, zodra een kwaadwillende het domein fritz.box (of nadat Netgear hun domeinen laat verlopen) weet te registreren en een pagina toont die als twee druppels water op die van mijn router lijkt, zou ik mijn login-gegevens aan een vreemde kunnen prijsgeven... Vandaar dat het zo belangrijk is dat domeinnamen in certificaten wereldwijd uniek zijn (en je daar dus ook geen RFC1918 IP-adressen voor moet gebruiken).

Ik heb wat vage ideeën wat hieraan gedaan zou kunnen worden, maar die zijn nog onvoldoende concreet (en het wordt een te lang verhaal vrees ik).

Dat is een mooi streven, maar zoals ik hierboven schreef: zodra een aanvaller toegang tot een device heeft, maakt het niet zoveel meer uit of de private key niet in handen van de aanvaller kan vallen.

Zodra je ontdekt dat een apparaat gecompromitteerd is, zou het kunnen helpen als je zeker weet dat de private key niet in handen van de aanvaller is gekomen. Aan de andere kant, als je een nieuw sleutelpaar en self-signed certificaat om die public key kunt maken en uploaden naar het apparaat (of het apparaat deze laten genereren), maakt die TPM ook niet zoveel meer uit.

Die TPM kan nuttig zijn als op een IoT-achtig device uitsluitend trusted (digitaal ondertekende) code kan draaien, maar dat is ontzettend lastig waterdicht te krijgen als je firmware-updates wilt installeren. En dat maakt het hobbyisten al gauw moeilijk of onmogelijk om alternatieve firmware te gebruiken (zoals een open source router OS). Daarbij lekken software/firmware fabrikanten te vaak code-signing private keys, en revocation (dus vervanging) van een private key in een TPM is natuurlijk -by design- hartstikke lastig, zo niet onmogelijk.

Ik zie de voordelen nog niet zo, maar laat me graag overtuigen met goede argumenten!

@Anoniem, vandaag, 01:54: ik vind jouw bijdrage wat lastig te lezen,maar als ik je goed begrijp zie je veel risico's bij "tijdelijk beveiliging uitschakelen" zoals de Sonos speakers doen - daar ben ik het mee eens, in elk geval voor grotere netwerken. Thuis ben ik zelf ook nogal voorzichtig, in de ogen van velen wellicht veel te overdreven.

Het is m.i. wel een leuke thread zo, dank aan allen voor de constructieve bijdragen!

Vroegâh had men een aparte configuratiepoort op routers e.d. (aparte aansluiting, serieel geloof ik, kan nu USB worden)
1. Pak laptop met een USB-touwtje erbij, en juiste software/driver
2. prik USB-kabel in laptop en de andere kant in configuratiepoort van het apparaat dat je wil configureren
3. naam/wachtwoord ter authenticatie
4. configureren maar
Simpel en doeltreffend. Okee, je moet lokaal aanwezig zijn, maar veiligheid heb je wat voor over.
Overigens hebben routerprodukten meestal een voorziening om remote in te kunnen loggen via de WAN als je dat nodig vindt. (meestal niet...)

Of.... gewoon even PuTTY op je laptop zetten en inloggen met SSH.

Zo doe ik dat ook (laptop-USBkabel-router), en aanvullend:
5. De router-software is open source dus zonder backdoor ... maar de OpenWRT software is er door de (Chinese) routerfabrikant in de fabriek al op gezet, in principe is het dan volgens mij niet uitgesloten dat er door de fabrikant toch wel een backdoor ("hidden user") aan is toegevoegd. Maar dat hoeft niet zo te zijn. Hoe controleer je de integriteit (hash) van de geinstalleerde software-versie?? Mijn idee is (maar ik ruil het graag tegen een beter idee) er een zelf gedownloade en gecontroleerde (sha256sum) OpenWRT versie op te installeren. En uiteraard een nieuwe username en password te gebruiken. Maar of dit dan voldoende is?

Ik vrees dat het vermoeden van Netgear, dat teveel van hun klanten dit niet kunnen, terecht is. En als zo'n kabeltje niet wordt meegeleverd, moet je deze (met aan beide kanten passende connectors) wel in huis hebben en kunnen vinden.

Het verbieden van IoT-achtige-devices (inclusief netwerkapparatuur) met beheerinterfaces die vanaf internet bereikbaar zijn (routeerbaar dus), vooral als deze met een standaard wachtwoord worden uitgeleverd, kon wel eens het beste zijn om mee te beginnen als je (als overheid of bijv. EU) internet veiliger wilt maken.

Gelukkig is er tot nu toe weinig van IPv6 terechtgekomen, anders was de puinhoop veel groter geweest (o.a. met botnets zoals Mirai). Immers, dankzij (P)NAT routers - vooral die waarin UPnP uit staat - moeten mensen extra moeite doen om elke van hun "smart" meuk als server op internet te ontsluiten.

Vroegâh had nog niet iedereen wat er in een usb apparaat zat.
Namelijk ook een chip die aan de stekker verbindingen is gekoppeld heeft.
Tegenwoordig is wel breder bekend dat die chips meer soortige taken toelaten dan je zou verwachten en willen.
Daarom geeft men ook het advies om bijvoorbeeld je usb apparaten enkel fysiek in de bijgeleverde appraten te steken.
Dus, steeks de usb-lader kabels van je telefoon enkel fysiek in dezelfde uitgereikte oplader stekker van de fabrikant.
Gebruik geen "compatible" apparaten daarnaast of ervoor in de plaats.
Steek het appraat ook niet in welk ander willekeurige usb poort om het op te laden, omdat nou eenmaal zou handig lijkt.
Als iemand dat echter wel met zijn telefoon heeft gedaan dan kan je die usb-socket en dus het IoT apparaat eigenlijk beter even onbetrouwbaar achten als openbare wifi-spots.
Overigens waren er ook al hacks met usb-aansluitingen mogelijk toen ziggo en knp de wonderlijk lumineuze gedachte gingen toepassen dat gebruikers bij het voor de 1e keer aansluiten van een adsl-modem door de klant dat ze dan maar ook even een usb-stick in hun router moesten plaatsen, gevolgd door wat handelingen.
Tel uit de vooruitgang.

Sinds de opkomst van firmware in flash-memory ben ik nog nooit een apparaat tegengekomen waarbij dat mogelijk was (in zeer oude systeempjes, die nog een EPROM in een voetje hadden, kon je die eruit halen en checken in bijv. een EPROM-programmer - maar die checksum was allesbehalve cryptografisch en kon daarom eenvoudig vervalst worden).

Bovenaan https://openwrt.org/docs/guide-quick-start/verify_firmware_checksum staat:
Als een server gehacked is of een foute beheerder heeft, biedt een hash die je van dezelfde server downloadt als de binary, natuurlijk geen enkele vorm van authenticiteit. Dat geldt ook als je van verschillende servers downloadt en terwijl de distributieserver al fout is.

In https://openwrt.org/docs/guide-user/security/release_signatures staat hoe je de authenticiteit controleert, d.w.z. heeft de binary een digitale handtekening die gezet is door iemand die de daarvoor noodzakelijke private key beschikt.

Belangrijk daarbij:
1) Je moet zeker weten dat de bijbehorende public key daadwerkelijk van iemand is die geautoriseerd is om OpenWRT binaries vrij te geven. Het is vaak lastig om dat vast te stellen;
2) Je kunt alleen maar hopen dat die persoon of personen zorgvuldig omspringen met die private key, om te voorkomen dat deze in verkeerde handen valt.

Als je niet goed weet hoe digitale handtekeningen werken, raad ik je aan om je er wat in te verdiepen. Desgewenst wil ik nog wel wat meer info geven.

Meestal blijft een deel van de firmware van de fabrikant achter, namelijk het deel dat ervoor zorgt dat je de functionele code kunt updaten of vervangen. Absolute zekerheid dat daar, of in de hardware (al dan niet met eigen firmware en/of microcode), geen backdoor in zit, heb je nooit - ook bij OpenWRT niet.

Kennelijk misbruik ook KPN in al haar Experiabox V10A modems een identiek certificaat + private key (bron: https://tweakers.net/nieuws/169354/kpn-klanten-kunnen-experiabox-v10a-niet-benaderen-door-verlopen-certificaat.html).

Dit komt aan het licht doordat KPN kennelijk vergeten is om dat (PKI-overheid) certificaat (met private key indien het sleutelpaar vervangen is) vóór de verloopdatum van afgelopen 3 juli in alle modems te vervangen. De modems zijn benaderbaar via https://mijnmodem.kpn/ waarbij de ingebouwde DNS server het juiste (RFC1918) IP-adres teruggeeft.

Certificaatgegevens (met dank aan Tweaker sciuro): https://crt.sh/?q=mijnmodem.kpn.

Doordat elk modem dezelfde private key heeft, moet je ervan uitgaan dat aanvallers daarover kunnen beschikken en eenvoudig de verbinding tussen jouw PC en het modem kunnen kapen als jij https://mijnmodem.kpn/ opent zonder dat dit een certificaatfoutmelding geeft (nu even niet door het verlopen certificaat). Dit is snake oil beveiliging, alleen bedoeld om foutmeldingen in browsers (bij -veiliger door TOFU- per-modem-unieke self-signed certificaten) te voorkomen.

Nb. bij het gebruik van DoH (of een handmatig ingestelde externe DNS server) werkt deze idioterie sowieso niet meer (of zou zelfs misbruikt kunnen worden door je met een willekeurig device op Internet te laten verbinden).

In de academische wereld zijn hier overigens nog wel wat papers/theses over geschreven. (Hint: zoek op de TU Delft repository naar IoT.) Hint 2: blockchain.

Het is heel hind(/t)erlijk als mensen alleen maar gaan lopen pronken met iets dat ze denken te weten.

Geef gewoon een URL en liefst kleine recap van een paper waarvan je vindt dat het iets relevants zegt over deze discussie.

Hint 2 is in elk geval geen aanbeveling om zoektijd te stoppen in de kans dat je ergens naar verwijst dat wat toevoegt.

IoT: Blijft slechts een niet-noodzakelijke gimmick. En vooral vrijblijvend: Toegevoegde waarde ontbreekt en het is de domme consument zelf die deze prullaria aanschaft en aan zijn router toevoegt.

Voor mij is elk ding aan internet een IoT.

Je zou onderscheid kunnen maken tussen devices met (beheer-) GUI (of evt. text-based interface) en de rest, maar ook dan vallen routers/modems onder die rest. Overigens hangen niet alle consumenten-IoT things aan hun eigen thuisrouter (denk aan "slimme" energieverbruikmeters en steeds meer auto's). De opkomst van 5G zou het aantal IoT's dat je niet zelf kunt "firewallen" wel eens flink kunnen doen toenemen, waarmee het meer een CoT (Cloud of Things) wordt.

En met routers/modems is het, net als bij andere IoT things, ook bar slecht gesteld qua security, aldus een eind juni gepubliceerd rapport: https://www.fkie.fraunhofer.de/content/dam/fkie/de/documents/HomeRouter/HomeRouterSecurity_2020_Bericht.pdf
(bron: https://www.zdnet.com/article/home-router-warning-theyre-riddled-with-known-flaws-and-run-ancient-unpatched-linux/).

Uit laatstgenoemde bron:

Wat versta je onder IoT? Een camera die kijkt hoeveel melk er in de koelkast staat? Dat staat iedereen vrij om wel/niet aan te schaffen. Dat is alleen een erg beperkte visie op IoT

Er is best veel zinnige IoT. Denk bv. aan water sensoren die de hoogte (en bv. temperatuur en/of vervuiling) van het water meten en doorgeven, om hiermee automatisch sluizen aan te sturen? Ook dat is IoT. En daarbij is authenticiteit (is dit *echt* de sensor die ik zelf heb neergezet?) en data integriteit (staat het water *echt* 20 cm te hoog?) vele malen belangrijker dan de vertrouwelijkheid. Want als ik als simpele hacker zonder kans op detectie of zelf berichten kan spoofen, of berichten kan aanpassen, kan ik daarmee bv. een polder onder water laten lopen, met alle schade die daarbij komt.

Veel van dit soort IoT gebruikt nu nog LoRa. Bij LoRa is authenticiteit en integriteit in basisvorm in het device embedded. Alleen enigsinds beperkt vanwege beschikbare bandbreedte en noodzaak tot laag stroom verbruik (denk aan sensoren die 10 jaar met een batterij moeten doen). In IoT op basis van 5G is er iets meer bandbreedte en kan je meer aan integriteit en authenticiteit doen.

Q