KTH-student avslöjar allvarliga brister i Verisures hemlarm

[lars_stefan_axelsson]

Jo men allt i livet är ju en massa kompromisser.... även ett hemlarm.

Ja precis. Jag ville inte säga något annat. Tvärtom.

- Jag prioriterar ett säkert brandskydd för vårt gamla hus när vi inte är hemma.


Verisures kameralösning med detektering och branddetektorer blev helt avgörande inkl att deras larmcentral direkt ser mha kamerorna vad som händer, tecken på inbrott eller en massa rök från en brand.

Och där är ju dessa larm ett stort fall framåt. Förmågan att svara på brand påverkas ju öht inte av om larmet är trådlöst eller inte. Tvärtom så är trådlösheten här antagligen ett plus eftersom det gör att man kan placera sensorer där de gör mest nytta snarare än dit man orkar dra tråd.

Sen kan man sedan grotta ner sig i detaljer men jag kan inte se något avgörande fel på Verisures lösning mer än kanske taggarna men det är långsökt hur man skulle nyttja det?

Precis. Och den som skulle kunna utnyttja taggarna är också den som står närmare att ta till mera otrevliga metoder om det inte skulle fungera.

 

[cpalm]

Nej, trådlösa hemlarm har en rad kända brister och svagheter. Det är inte för inte som säkerhetsklassade larm inte kan vara trådlösa.

Nuförtiden finns i och för sig larmklass R och SSF 140 för trådlösa larm. Och alla de stora larmtillverkarna har väl trådlösa alternativ i sina kommersiella system(?) Hur försäkringsbolagen i dagsläget ställer sig till det har jag förvisso ingen uppfattning om annat än att det inte alltid ställs krav på en specifik larmklass, men nog känns det som att trådlöst är på god väg att etablera sig även i seriösare sammanhang.

Även om tekniken har sina ofrånkomliga brister finns det trots allt andra faktorer som i praktiken är större problem, som t.ex. normala inställelsetider.

 

[lars_stefan_axelsson]

Nuförtiden finns i och för sig larmklass R och SSF 140 för trådlösa larm. Och alla de stora larmtillverkarna har väl trådlösa alternativ i sina kommersiella system(?) Hur försäkringsbolagen i dagsläget ställer sig till det har jag förvisso ingen uppfattning om annat än att det inte alltid ställs krav på en specifik larmklass, men nog känns det som att trådlöst är på god väg att etablera sig även i seriösare sammanhang.

Ja, men de uppfyller inte SS130, vilket enligt tidigare länk är ett problem för företag eftersom de oftast har det kravet. Det rimmar med kraven på skalskydd i övrigt.

Mao, i de fall försäkringsbolaget faktiskt ställer lite krav på skalskydd och säkerhet, då duger inte trådlösa larm. De är för enkla att slå ut.

Så mitt stalltips är att man visst kommer hävda att det nu är så mycket bättre, och att det visst fungerar (de är nämligen mycket billigare och enklare för larmföretagen att installera och hantera), men de kravställare som vet och kan och ställer faktiska krav, de kommer aldrig att acceptera den här tekniken i sin nuvarande tappning.

Därmed inte sagt att det inte kan fungera i andra sammanhang där det inte ställs så höga krav.

Även om tekniken har sina ofrånkomliga brister finns det trots allt andra faktorer som i praktiken är större problem, som t.ex. normala inställelsetider.

Det är iofs en annan och mera intressant fråga. I de fall jag sett/arbetat med tekniken (och det skall inte överdrivas på något sätt, det här är ett sidospår för mig) så har inte inställelsetid varit ett problem....

 

[Boilerplate4U]

Vi kan om vi vill krångla till det ännu mer. Det är inte ens säkert att en bricka som inte går att klona leder till ett säkrare system än ett där det går att göra det. För om ett hot minskar så kan ett annat, värre, öka som följd av det.

Två historiska exempel visar på problemet. I USA innan förra sekelskiftet så blev banksäkerheten bättre iom att man satsade mer på bättre bankvalv med mer avancerad teknik. Det blev så svårt att bryta sig in och stjäla pengar att bankrånarna bytte metod. Man tog istället bankkamrerens familj gisslan mitt i natten för att tvinga honom att följa med andra i ligan till banken och helt enkelt låsa upp valvet.

Som svar på det så uppfann James Sargent tidlåset 1873. Dvs ett lås som man låser valvet med på kvällen och som hindrar att valvet öppnas innan rätt tid påföljande morgon. Ingen kan låsa upp valvet under tiden som tidlåset spärrar det. (Testades första gången skarpt redan 1875 med önskat resultat.)

Vi såg samma fenomen i lite mer närtid iom att billås och startspärrar blev elektroniska. I USA så ledde det till en ökning av s.k. carjackings, alltså "bilrån" eftersom det blev lättare att hota föraren när bilen redan var upplåst och igång med nyckeln i, än att stjäla bilen från gatan. Jag tror de flesta håller med om att även om det är trist att få bilen stulen under natten, så är det ännu tristare att få en pistol körd i nyllet när man står i kö eller vid ett rödljus. (Jag har ingen klockren referens här, men ökningen av GPS-tracking, remove immobilization osv. går hand i hand med ökningen av "bilrån")

Så varje skydd som ökar tröskeln kommer att solla bort en hel del angripare som inte längre tycker det är värt det. Men den kommer också att motivera en del av de som är kvar att gå ännu längre och ta till ännu grövre metoder. Och det är inte alltid önskvärt eftersom det kan öka den personliga risken.

Allt är en avvägning. Svaret på alla intressant frågor är alltid: "Det beror på..."

Haha, information overload och ett stänk av whataboutism för en så enkel fråga! 😉

Men jag fattar poängen. Ingen kedja är ju starkare än sin svagaste länk och det gäller även beteendeförändringar hos angripare. Däremot känns det lite långsökt att en stark kryptering i taggar/nyckelbrickor skulle trigga samma nivå av eskalering som bankrån med gisslantagning eller carjackings. Eller... 😁

Men tillbaka till min ursprungsfråga som du så snällt svarade på: stark kryptering är i princip standard idag till en väldigt liten kostnad. Mig veterligen har ingen lyckats knäcka en teknik där huvudnyckeln är säkert lagrad i låst hårdvara för t.ex. taggar och liknande system. Därav min fundering.

---

EDIT:
Ytterligare en whataboutism och OT: Många implementationer av moderna säkerhetsrelaterade lösningar har infört Zero Trust med end-to-end-kryptering för att just eliminera osäkra mellanlager. Jag tänkte på tidigare incidenter med tex RCO.

EDIT 2:
Whataboutism #2 och helt OT: angående Must senaste drag att införa Signal för "vardagskommunikation" just pga stödet för end-to-end-kryptering; hur kan de vara säker på detta när det handlar om en tredjepartsapp?!

 

[cpalm]

Mao, i de fall försäkringsbolaget faktiskt ställer lite krav på skalskydd och säkerhet, då duger inte trådlösa larm. De är för enkla att slå ut.

Även trådade larm har i och för sig sina brister. Inte minst i larmklass 2.
Det som är avgörande i praktiken är väl att man får sabotagelarm inom rimlig tid.
Har varit med och använt trådlösa larm på skyddsobjekt, så även i extremt seriösa sammanhang används trådlösa larmlösningar, givetvis med en medvetenhet kring deras egenskaper.

Det är iofs en annan och mera intressant fråga. I de fall jag sett/arbetat med tekniken (och det skall inte överdrivas på något sätt, det här är ett sidospår för mig) så har inte inställelsetid varit ett problem....

1 timme kan vara normal avtalsenlig inställelsetid, och då spelar någon minuts fördröjning på larmet förmodligen mindre roll.

 

[lars_stefan_axelsson]

... givetvis med en medvetenhet kring deras egenskaper.

Ja, jag vill inte spåra ur diskussionen (mer än jag redan gjort Mina poänger var just att man blir aldrig perfekt säker, allt är en avvägning och hur man än vänder sig har man röven bak.

I ditt fall så pratar vi om proffs som kan och gör analyser och just dessa avvägningar; väl medveten (eller iaf så gott som går) om styrkor och svagheter som alla lösningar för med sig.

Det är dock lite överkurs för den som bara vill ha ett villalarm i största allmänhet, och vad man än väljer där så får man i stort sett samma sak. Det står och faller inte med enskilda detaljer i de olika leverantörernas lösningar. Svagheter på systemnivå (trådlöshet) dominerar helt problembilden.

Om man skulle gå in på dessa detaljskillnader i utförandet så har man i så fall större nytta av att i så fall ta ett längre steg tillbaka och se till hela sin situation. *) Då kommer man oftast fram till att det är helt andra risker som dominerar.


*) Som en expert i en gammal säkerhetshandbok uttryckte det: "Men först skall jag först lära er hur man korrekt lagrar mat i ett kylskåp. Tro mig, om ni skall verka i de här länderna så kommer ni att ligga golvade av matförgiftning betydligt oftare än som följd av någon av alla de andra riskerna vi kommer att prata om här..."

 

[paralun]

1 timme kan vara normal avtalsenlig inställelsetid, och då spelar någon minuts fördröjning på larmet förmodligen mindre roll.

Jo men helt avgörande för vår del är kamerafunktionaliteten som tar bort inställelsetider både för inbrott samt brand. Monterade i två hallar, uppe och nere och integritet är beaktat.

Sen är det ju en kostnadsfråga om man vill tråda allting.

I slutändan blir det en balansgång mellan sannolikheter och pris och jag är själv nöjd.

Om videodetektorn och olika användningar samt viktigaste att larmcentralen direkt ser vad som händer.
https://www.verisure.se/hemlarm/produkter--tjanster/videodetektor

 

[merbanan]

Jag har varken tid eller lust att läsa rapporten just nu, men den finns här för den intresserade:
[länk]

Det är en fint skriven rapport men i princip så visar den bara att Verisures system är tillräckligt "säkert".

Det man hade velat få reda på är ju det underliggande rf-protokollet och hur man dekrypterar alla meddelanden. Men det är inte riktigt syftet med denna rapport.

 

[cpalm]

hur kan de vara säker på detta när det handlar om en tredjepartsapp?!

https://github.com/signalapp
Det är öppen källkod, så de kan hämta ner den, säkerhetsgranska implementationen och bygga en egen version av appen för att försäkra sig om att ingen utomstående part är inblandad.

 

[Boilerplate4U]

[länk]
Det är öppen källkod, så de kan hämta ner den, säkerhetsgranska implementationen och bygga en egen version av appen för att försäkra sig om att ingen utomstående part är inblandad.

Aha, nu trillade polletten ner! Tack! 😀 Jag visste inte det vara samma "Signal" som finns på Google Play och Apple Appstore.

 

[lars_stefan_axelsson]

[länk]
Det är öppen källkod, så de kan hämta ner den, säkerhetsgranska implementationen och bygga en egen version av appen för att försäkra sig om att ingen utomstående part är inblandad.

Jag har fått indikationer på att ett gäng kompetenta människor kommer att uttala sig om just den här frågan i P1:s Godmorgon Världen nu på söndag. Ifall någon skulle vara intresserad...

Och fortfarande lyssnar på radio...

 

[Boilerplate4U]

Jag har fått indikationer på att ett gäng kompetenta människor kommer att uttala sig om just den här frågan i P1:s Godmorgon Världen nu på söndag. Ifall någon skulle vara intresserad... Och fortfarande lyssnar på radio...

Tack för tipset! Godmorgon Världen ju en självklar del av poddlistan, eller hur?!

 

[pedersparell]

Intressant! Kan du beskriva vilken metod du använde? Som jag förstått det ska DESFire med AES-128 och slumpmässig UID i princip vara omöjlig att klona.

Eftersom jag tillhör gruppen "Etiska hackare" vill jag kanske inte vara för tydlig i ett publikt forum.

Men vi använde bara en publikt tillgänglig "hacking gadget" med stöd för detta (bl.a. DESFire, vet inte vilka versioner/generationer).

Jag ska inte påstå att jag är helt påläst om den bakomliggande metoden, min kollega har lekt mer med enheten, gjorde själva kloningen och kan en hel del mer än mig om detta. Men jag kan nog medge att klonen faktiskt inte blir helt komplett, vilket dock inte spelar större roll eftersom man, som jag förstod det, kombinerar det hela med en attack mot protokollet, så med ett mindre antal snabba meddelanden mellan emulatorn och kortläsaren kan sista delen beräknas/gissas på något sätt, den kanske väntar på rätt challenge från kortläsaren eller likande. Jag upplevde det som bara någon sekunds fördröjning innan klonen accepterades av kortläsaren.

Oavsett behöver man ju även oftast även ange en tillhörande pin när det gäller passagesystem, vilket ju inte klonen kan bistå med.

 

[Boilerplate4U]

Eftersom jag tillhör gruppen "Etiska hackare" vill jag kanske inte vara för tydlig i ett publikt forum.

Men vi använde bara en publikt tillgänglig "hacking gadget" med stöd för detta (bl.a. DESFire, vet inte vilka versioner/generationer).

Jag ska inte påstå att jag är helt påläst om den bakomliggande metoden, min kollega har lekt mer med enheten, gjorde själva kloningen och kan en hel del mer än mig om detta. Men jag kan nog medge att klonen faktiskt inte blir helt komplett, vilket dock inte spelar större roll eftersom man, som jag förstod det, kombinerar det hela med en attack mot protokollet, så med ett mindre antal snabba meddelanden mellan emulatorn och kortläsaren kan sista delen beräknas/gissas på något sätt, den kanske väntar på rätt challenge från kortläsaren eller likande. Jag upplevde det som bara någon sekunds fördröjning innan klonen accepterades av kortläsaren.

Oavsett behöver man ju även oftast även ange en tillhörande pin när det gäller passagesystem, vilket ju inte klonen kan bistå med.

Okay, då misstänker jag att ni lekt med den gamla MIFARE Classic från 1994.

 

[pedersparell]

Oj nej. En mycket nyare enhet och en modern aktuell installation av passersystemet, med tillhörande aktuella kort.