Knarkarkvart på TripAdvisor?
Den här då... Kollega Martin skickar en länk där en anställd på TripAdvisor berättar att root-konton används väldigt promiskuöst i deras system:
Pfft. "root on your box" is so last week. Here at TripAdvisor, we give engineers root on EVERY box. I'd add "modulo the live site", but when I needed that, it was made available.
Inlägget är lite mer än ett halvår gammalt. Det här är ett tydligt tecken på en s k knarkarkvart.
(För er som missade det häromdagen, medlemmar på siten TripAdvisor, en enorm webbsida för folk som gillar att resa, fick sina mailadresser stulna.)
--
Stefan Pettersson
Pfft. "root on your box" is so last week. Here at TripAdvisor, we give engineers root on EVERY box. I'd add "modulo the live site", but when I needed that, it was made available.
Inlägget är lite mer än ett halvår gammalt. Det här är ett tydligt tecken på en s k knarkarkvart.
(För er som missade det häromdagen, medlemmar på siten TripAdvisor, en enorm webbsida för folk som gillar att resa, fick sina mailadresser stulna.)
--
Stefan Pettersson
Att hacka skyltar
I en period där det har skett ovanligt många, allvarliga högprofilintrång (RSA, Comodo, franska finansdepartementet, TripAdvisor, Europakommissionen, m f l) kan det vara på sin plats med några, lite mer harmlösa, exempel.
Filmen som visar hur man hackar en billboard på Times Square med en iPhone var ju (uppenbart) fejkad. Det betyder förstås inte att det är omöjligt. Minns t ex de dynamiska vägskyltarna i Texas som hade default-lösenord för ett år sedan:
Eller ett färskare exempel; en reklamskärm längs en motorväg i Ryssland visade porrfilm i 20 minuter i januari. Ni behöver inte vara oroliga dock, faran är över, den hemska förövaren är gripen, åtalad och dömd till sex år i fängelse:
Trevlig helg!
--
Stefan Pettersson
Filmen som visar hur man hackar en billboard på Times Square med en iPhone var ju (uppenbart) fejkad. Det betyder förstås inte att det är omöjligt. Minns t ex de dynamiska vägskyltarna i Texas som hade default-lösenord för ett år sedan:
Eller ett färskare exempel; en reklamskärm längs en motorväg i Ryssland visade porrfilm i 20 minuter i januari. Ni behöver inte vara oroliga dock, faran är över, den hemska förövaren är gripen, åtalad och dömd till sex år i fängelse:
Trevlig helg!
--
Stefan Pettersson
Mardrömmen: intrång hos en CA
För några veckor sedan skrev jag om första intrycket vid blindträffar, att det är svårt att verifiera en person om man inte vet något om dem på förhand. Jag länkade också till uppsatsen Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL (pdf) som handlar om hur en stat skulle kunna tvinga en CA att utfärda certifikat till t ex mail.google.com.
Ett annat alternativ är förstås att bryta sig in hos en CA eller deras partners och signera ett par certifikat på egen hand.
Det är precis vad som hände en av de större, Comodo, den 15 mars. Läs deras incidentrapport och deras kommentarer i bloggform. De misstänker att Iran ligger bakom attacken.
Det kommer definitivt att vara lärorikt att följa den här historien. Ful-certifikat på det här sättet är ett fruktat säkerhetsproblem. En variant på lösningen som presenteras i Certified Lies skulle dock kunna skydda mot sånt här. Åtminstone i teorin.
--
Stefan Pettersson
Ett annat alternativ är förstås att bryta sig in hos en CA eller deras partners och signera ett par certifikat på egen hand.
Det är precis vad som hände en av de större, Comodo, den 15 mars. Läs deras incidentrapport och deras kommentarer i bloggform. De misstänker att Iran ligger bakom attacken.
Det kommer definitivt att vara lärorikt att följa den här historien. Ful-certifikat på det här sättet är ett fruktat säkerhetsproblem. En variant på lösningen som presenteras i Certified Lies skulle dock kunna skydda mot sånt här. Åtminstone i teorin.
--
Stefan Pettersson
Attacken mot RSA SecurID
Mångas favoritsäkerhetsfarbror Steven M. Bellovin, känd för sina RFC:er och boken Firewalls and Internet Security från 1994, har resonerat en del kring vad RSA-angriparna egentligen kom över och vad det kan leda till. Inlägget The RSA SecurID Problem tonar ner komplexiteten i SecurID och beskriver dess konceptuella funktion väldigt bra.
Det värsta som kan hända är väl mer eller mindre att RSA har en master secret som allt står och faller med. Angående nyckeln K som varje token använder för att generera sina koder:
It is tempting to calculate K=G(K',serial_number), where K' is a closely-held RSA secret and G is some other hash function. The risk here is discovery of K'; any new devices would be at risk of compromise if the attacker knew the serial numbers associated with some target customer. This is the really big question: how are the K values generated?
Men som Bellovin själv säger, det är förmodligen ganska otroligt.
--
Stefan Pettersson
Det värsta som kan hända är väl mer eller mindre att RSA har en master secret som allt står och faller med. Angående nyckeln K som varje token använder för att generera sina koder:
It is tempting to calculate K=G(K',serial_number), where K' is a closely-held RSA secret and G is some other hash function. The risk here is discovery of K'; any new devices would be at risk of compromise if the attacker knew the serial numbers associated with some target customer. This is the really big question: how are the K values generated?
Men som Bellovin själv säger, det är förmodligen ganska otroligt.
--
Stefan Pettersson
Riskanalysens mörka hemlighet -- del 2
I förra delen diskuterade vi konsekvensproblemet; nästa problem med riskanalyser är sannolikhetsproblemet.
Sannolikhetsproblemet
Det vi vill göra med faktorn SANNOLIKHET är att avgöra hur mycket vi behöver bry oss om en KONSEKVENS. Kommer konsekvensen att påverka oss ofta? Kommer den att inträffa överhuvudtaget? En lindrig konsekvens som påverkar väldigt ofta kan ju, åtminstone teoretiskt, vara värre än en allvarlig konsekvens som slår sällan. Det är lite som, vad är värst: att bli träffad av en tennisboll i huvudet 30-40 gånger per dag eller att bli knivhuggen var 70:e år?
Det finns de som är väldigt bra på sannolikheter; Transportstyrelsen har t ex en rätt god uppfattning om hur vanligt det är att personbilar krockar i rondeller jämfört med fyrvägskorsningar. Tyvärr handlar det om fel sorts säkerhet, det är olyckor, inte attacker. Polisen då? De arbetar ju med att förhindra attacker (fast de kallar det för brott). I programmet Efterlyst har t ex Leif GW Persson lärt oss att det i en klar majoritet av fallen är en manlig bekant som är ansvarig när en kvinna har blivit misshandlad.
För polisen, vars verksamhet i stor utsträckning kretsar kring utredningar after-the-fact, är kunskaper om sådana sannolikheter av stort värde. Det passar dock inte oss. Vi är mer i läget där vi vill veta hur stor sannolikheten är att en familjemedlem blir misshandlad, inte hur stor sannolikhet det är att det skulle vara en manlig bekant som är förövare.
"Men", säger Leif GW, "det är enkelt, det beror ju på vad det är för familjemedlem. Din son löper t ex större risk att bli misshandlad än din dotter eftersom män blir misshandlade oftare än kvinnor." Här är vi något på spåren. Vetskapen att sonen är utsatt för större risk än dottern kan vara värdefull men det är inte vad vi är ute efter, vi vill veta hur stor risk sonen är utsatt för. "Äsch", svarar Leif GW, "man brukar väl säga att män i snitt blir misshandlade var 26:e år. Yngre män i tjugoårsåldern får väl spö dubbelt så ofta men det finns andra faktorer som väger in också."
Så ju mer vi vet om analysobjektet (sonen) desto mer rättvisande sannolikhet kan Leif GW ge oss. Nu är vi verkligen något på spåren.
Anta att vi är föräldrar och har enäggstvillingar. Vi vill veta hur stor risk de löper att bli misshandlade. Med hjälp av brottsstatistikoraklet Leif GW kan vi analysera situationen:
Det är ju smått fantastiskt var man kan komma med lite analys. Men don't get your hopes up, inom IT-säkerhet har vi det långt ifrån lika förspänt som Polisen har. Sannolikhetsproblemet är att vi sällan är säkra på vad som påverkar sannolikheten och att vi inte har någon aning om hur sannolikheten påverkas.
I klartext betyder det här att vi i regel inte vet vad som påverkar sannolikheten att ett system blir hackat. Samtidigt, om vi nu skulle ha det, har vi definitivt ingen aning om i vilken utsträckning det påverkar.
Vi sitter och tittar på ett arkitekturdokument, konstaterar att konsekvenserna av att en angripare får kontroll över ett reverse-proxy är rätt stora och behöver bilda oss en uppfattning om hur sannolikt det är att det händer. Vår sannolikhetsbedömning här avgör huruvida det hamnar högst upp på listan eller om det hamnar under något-att-bry-sig-om-strecket. Spelar det roll att det är Apache 2 på Windows? Hur stor roll spelar det?
Epilog
Vi har ingen Transportstyrelse, vi har inget Brottsförebyggande råd, våra angripare är för intelligenta och de tekniska förutsättningarna för både oss och angriparna ändras för snabbt. Vi har inte år av samlad statistik att luta oss tillbaka mot. Förutsättningarna är såpass dåliga att man undrar om de ens är värda att försöka sammanställa. Vi är beroende av aktuell kunskap och erfarenhet hos individer när det gäller att bedöma risker, utstuderade metoder som resulterar i värden erbjuder ingen genväg.
Vanligen är försvaret mot sådana här anklagelser något i stil med "man behöver ju inte vara helt exakt, det viktiga är ju att man försöker". Ja, på sätt och vis. Värdet av att olika personer samlas och gnuggar geniknölarna kring det här är stort men man kanske ska nöja sig med en konsekvensanalys och hålla tungan rätt i mun när (om) sannolikheten ska bedömas. Sannolikheter rörande säkerhet som påverkar våra verkliga liv kan vara enkla att bedöma. Vår värld inom IT-säkerhet är mycket svårare, de flesta av oss har en dåligt utvecklad intution.
--
Stefan Pettersson
Sannolikhetsproblemet
Det vi vill göra med faktorn SANNOLIKHET är att avgöra hur mycket vi behöver bry oss om en KONSEKVENS. Kommer konsekvensen att påverka oss ofta? Kommer den att inträffa överhuvudtaget? En lindrig konsekvens som påverkar väldigt ofta kan ju, åtminstone teoretiskt, vara värre än en allvarlig konsekvens som slår sällan. Det är lite som, vad är värst: att bli träffad av en tennisboll i huvudet 30-40 gånger per dag eller att bli knivhuggen var 70:e år?
Det finns de som är väldigt bra på sannolikheter; Transportstyrelsen har t ex en rätt god uppfattning om hur vanligt det är att personbilar krockar i rondeller jämfört med fyrvägskorsningar. Tyvärr handlar det om fel sorts säkerhet, det är olyckor, inte attacker. Polisen då? De arbetar ju med att förhindra attacker (fast de kallar det för brott). I programmet Efterlyst har t ex Leif GW Persson lärt oss att det i en klar majoritet av fallen är en manlig bekant som är ansvarig när en kvinna har blivit misshandlad.
För polisen, vars verksamhet i stor utsträckning kretsar kring utredningar after-the-fact, är kunskaper om sådana sannolikheter av stort värde. Det passar dock inte oss. Vi är mer i läget där vi vill veta hur stor sannolikheten är att en familjemedlem blir misshandlad, inte hur stor sannolikhet det är att det skulle vara en manlig bekant som är förövare.
(Varning för fabricerade citat och påhittad statistik nedanför.)
"Men", säger Leif GW, "det är enkelt, det beror ju på vad det är för familjemedlem. Din son löper t ex större risk att bli misshandlad än din dotter eftersom män blir misshandlade oftare än kvinnor." Här är vi något på spåren. Vetskapen att sonen är utsatt för större risk än dottern kan vara värdefull men det är inte vad vi är ute efter, vi vill veta hur stor risk sonen är utsatt för. "Äsch", svarar Leif GW, "man brukar väl säga att män i snitt blir misshandlade var 26:e år. Yngre män i tjugoårsåldern får väl spö dubbelt så ofta men det finns andra faktorer som väger in också."
Så ju mer vi vet om analysobjektet (sonen) desto mer rättvisande sannolikhet kan Leif GW ge oss. Nu är vi verkligen något på spåren.
Anta att vi är föräldrar och har enäggstvillingar. Vi vill veta hur stor risk de löper att bli misshandlade. Med hjälp av brottsstatistikoraklet Leif GW kan vi analysera situationen:
- Tvillingarna är män och borde därför bli misshandlade, i snitt, var 26:e år.
- Tvillingarna är män och mellan 20 och 30 år gamla och borde därför misshandlade var 13:e år.
- Tvillingarna är män, 20-30 år gamla och är ofta inne i stan på natten. De blir därför misshandlade var åttonde år.
- Tvillingarna är män, 20-30 år gamla, tillbringar mycket tid inne i stan och har flera kompisar som är kriminella. Det borde innebära att de blir misshandlade var tredje år.
- Den ena tvillingen har 200 000 kr i spelskulder till maffian. Han blir hotad och misshandlad flera gånger i veckan.
- Den andra tvillingen doktorerar i konflikthantering och blir nästan aldrig misshandlad.
Det är ju smått fantastiskt var man kan komma med lite analys. Men don't get your hopes up, inom IT-säkerhet har vi det långt ifrån lika förspänt som Polisen har. Sannolikhetsproblemet är att vi sällan är säkra på vad som påverkar sannolikheten och att vi inte har någon aning om hur sannolikheten påverkas.
I klartext betyder det här att vi i regel inte vet vad som påverkar sannolikheten att ett system blir hackat. Samtidigt, om vi nu skulle ha det, har vi definitivt ingen aning om i vilken utsträckning det påverkar.
Vi sitter och tittar på ett arkitekturdokument, konstaterar att konsekvenserna av att en angripare får kontroll över ett reverse-proxy är rätt stora och behöver bilda oss en uppfattning om hur sannolikt det är att det händer. Vår sannolikhetsbedömning här avgör huruvida det hamnar högst upp på listan eller om det hamnar under något-att-bry-sig-om-strecket. Spelar det roll att det är Apache 2 på Windows? Hur stor roll spelar det?
Epilog
Vi har ingen Transportstyrelse, vi har inget Brottsförebyggande råd, våra angripare är för intelligenta och de tekniska förutsättningarna för både oss och angriparna ändras för snabbt. Vi har inte år av samlad statistik att luta oss tillbaka mot. Förutsättningarna är såpass dåliga att man undrar om de ens är värda att försöka sammanställa. Vi är beroende av aktuell kunskap och erfarenhet hos individer när det gäller att bedöma risker, utstuderade metoder som resulterar i värden erbjuder ingen genväg.
Vanligen är försvaret mot sådana här anklagelser något i stil med "man behöver ju inte vara helt exakt, det viktiga är ju att man försöker". Ja, på sätt och vis. Värdet av att olika personer samlas och gnuggar geniknölarna kring det här är stort men man kanske ska nöja sig med en konsekvensanalys och hålla tungan rätt i mun när (om) sannolikheten ska bedömas. Sannolikheter rörande säkerhet som påverkar våra verkliga liv kan vara enkla att bedöma. Vår värld inom IT-säkerhet är mycket svårare, de flesta av oss har en dåligt utvecklad intution.
--
Stefan Pettersson
Riskanalysens mörka hemlighet
Det är en gammal sanning att hävda att säkerhet är riskhantering. Inget ont om det. Riskanalys däremot, en av de gängse metoderna för att hantera risker, hur det med dem? Är riskanalys verkligen en bra idé?
Riskanalys i teorin
Riskanalyser genomförs i bl a utvecklingsprojekt i syfte att avgöra vilken typ och nivå av "säkerhet" som behövs för att uppnå en "tillräckligt låg risknivå". Först, låt oss normalisera våra begrepp. Vi håller det enkelt och nöjer oss med att
där KONSEKVENS är den negativa effekten av att något (i regel oönskat) inträffar och SANNOLIKHET är, ja, sannolikheten att det inträffar. RISK defineras sedan helt enkelt som produkten av dessa, d v s det är en uppskattning av hur ofta något slår och hur hårt det slår.
Riskanalys i praktiken
Ett riskanalysarbete kan innefatta att en samling personer som har kunskaper om ett analysobjekt, ett mailsystem t ex, sätter sig runt ett bord och brainstormar scenarier som kan leda till oönskade konsekvenser för att sedan bedöma sannolikheten att de inträffar. Idéer diskuteras fram och tillbaka, vissa saker kommer man överens om, vissa inte. Ofta utmynnar arbetet sedan i en lista på scenarier, konsekvenser, sannolikheter och riskvärden, sorterade efter de senare. Projektet ska sedan använda denna lista för att prioritera i säkerhetsarbetet.
Riskanalys i verkligheten
Det finns två relativt uppenbara problem med riskbegreppet som det är definierat ovan: (1) hur bedömer vi konsekvensen? och (2) hur bedömer vi sannolikheten?
Konsekvensproblemet
Konsekvensproblemet är enklast att förklara. För analysobjektet mailsystem, tänk scenariot angripare skickar mail med vår domän som avsändare. En rimlig och fullt tänkbar risk (ibland används begreppet risk slarvigt såhär). Vad är konsekvensen av detta för oss som företag? Redan här stöter vi på problem; konsekvenserna kan vara flera beroende på vad mailet ifråga innehåller och vem det skickas till.
Scenariot måste specificeras; angripare skickar mail till vår kund och utger sig för att vara oss. Det är för öppet, vi kan fortfarande inte bedöma konsekvensen. Vad sägs om angripare lurar till sig kundens lösenord genom att utge sig för att vara oss. Mja, vi är fortfarande inte där, vad kan de göra med lösenordet? Sabba för kunden? Tappar vi kundens förtroende då? Tappar vi kunden? Vad innebär det? Här börjar vi närma oss konsekvensen.
Det stämmer ju att den enda konsekvens ett företag bryr sig om är den som kan mätas i någon valuta. Förutom i enstaka fall är det generellt slöseri med tid att sikta på monetära konsekvenser. Istället brukar man falla tillbaka på någon diskret skala i stil med obetydlig, lindrig, betydlig och allvarlig för att göra bedömningen.
Konsekvensproblemet är att medan vi närmar oss ett tillräckligt specifikt scenario där konsekvensen är möjlig att uppskatta förlorar vi täckning. Det är tydligt ovan att lura till sig lösenord är en specificering av attacker som involverar att spoofa avsändardomäner i mail. Vi täcker inte lika många scenarier helt enkelt, nu måste vi t ex också ta ställning till vad som händer om mailet till kunden ovan syftar till något annat eller är riktat till en leverantör istället.
Att vi behöver specifiera oss så här gör att processen tar längre tid, att det resulterar i mera utdata, att det blir svårare att överblicka o s v. Det är inte mycket att göra åt. Så är det när man arbetar med komplicerade system. Konsekvensproblemet är inte allvarligt, bara jobbigt.
Vi tar sannolikhetsproblemet i en uppföljande post. Fortsättning följer...
--
Stefan Pettersson
Riskanalys i teorin
Riskanalyser genomförs i bl a utvecklingsprojekt i syfte att avgöra vilken typ och nivå av "säkerhet" som behövs för att uppnå en "tillräckligt låg risknivå". Först, låt oss normalisera våra begrepp. Vi håller det enkelt och nöjer oss med att
RISK = KONSEKVENS × SANNOLIKHET
där KONSEKVENS är den negativa effekten av att något (i regel oönskat) inträffar och SANNOLIKHET är, ja, sannolikheten att det inträffar. RISK defineras sedan helt enkelt som produkten av dessa, d v s det är en uppskattning av hur ofta något slår och hur hårt det slår.
Riskanalys i praktiken
Ett riskanalysarbete kan innefatta att en samling personer som har kunskaper om ett analysobjekt, ett mailsystem t ex, sätter sig runt ett bord och brainstormar scenarier som kan leda till oönskade konsekvenser för att sedan bedöma sannolikheten att de inträffar. Idéer diskuteras fram och tillbaka, vissa saker kommer man överens om, vissa inte. Ofta utmynnar arbetet sedan i en lista på scenarier, konsekvenser, sannolikheter och riskvärden, sorterade efter de senare. Projektet ska sedan använda denna lista för att prioritera i säkerhetsarbetet.
Riskanalys i verkligheten
Det finns två relativt uppenbara problem med riskbegreppet som det är definierat ovan: (1) hur bedömer vi konsekvensen? och (2) hur bedömer vi sannolikheten?
Konsekvensproblemet
Konsekvensproblemet är enklast att förklara. För analysobjektet mailsystem, tänk scenariot angripare skickar mail med vår domän som avsändare. En rimlig och fullt tänkbar risk (ibland används begreppet risk slarvigt såhär). Vad är konsekvensen av detta för oss som företag? Redan här stöter vi på problem; konsekvenserna kan vara flera beroende på vad mailet ifråga innehåller och vem det skickas till.
Scenariot måste specificeras; angripare skickar mail till vår kund och utger sig för att vara oss. Det är för öppet, vi kan fortfarande inte bedöma konsekvensen. Vad sägs om angripare lurar till sig kundens lösenord genom att utge sig för att vara oss. Mja, vi är fortfarande inte där, vad kan de göra med lösenordet? Sabba för kunden? Tappar vi kundens förtroende då? Tappar vi kunden? Vad innebär det? Här börjar vi närma oss konsekvensen.
Det stämmer ju att den enda konsekvens ett företag bryr sig om är den som kan mätas i någon valuta. Förutom i enstaka fall är det generellt slöseri med tid att sikta på monetära konsekvenser. Istället brukar man falla tillbaka på någon diskret skala i stil med obetydlig, lindrig, betydlig och allvarlig för att göra bedömningen.
Konsekvensproblemet är att medan vi närmar oss ett tillräckligt specifikt scenario där konsekvensen är möjlig att uppskatta förlorar vi täckning. Det är tydligt ovan att lura till sig lösenord är en specificering av attacker som involverar att spoofa avsändardomäner i mail. Vi täcker inte lika många scenarier helt enkelt, nu måste vi t ex också ta ställning till vad som händer om mailet till kunden ovan syftar till något annat eller är riktat till en leverantör istället.
Att vi behöver specifiera oss så här gör att processen tar längre tid, att det resulterar i mera utdata, att det blir svårare att överblicka o s v. Det är inte mycket att göra åt. Så är det när man arbetar med komplicerade system. Konsekvensproblemet är inte allvarligt, bara jobbigt.
Vi tar sannolikhetsproblemet i en uppföljande post. Fortsättning följer...
--
Stefan Pettersson
Bifogade filer till franska regeringen
Flera datorer tillhörande franska regeringen har hackats. Enligt utsago har det skett med hjälp av övertygande mail till rätt personer. Mail med bifogade filer som kunde köra kod på något sätt för att skapa ett brohuvud åt angriparna.
Visst har vi sett det förut. T ex i januari förra året i samband med att Google och en del andra företag blev angripna av vad som verkade vara Kinesiska staten. Eller varför inte när samma gäng var ute efter Dalai Lama och tibetaktivister. (Vem kan sjunka så lågt att de angriper en spirituell ledare, förresten?)
I inlägget jag skrev då, Google, Adobe, Kina och trojaner, refererade jag till några läsvärda artiklar och påbörjade en lista på vad man kan göra för att motverka liknande attacker. Det finns nämligen ingen produkt man kan installera för att värja sig från detta, oavsett vad leverantörerna hävdar. Från förra posten:
--
Stefan Pettersson
Visst har vi sett det förut. T ex i januari förra året i samband med att Google och en del andra företag blev angripna av vad som verkade vara Kinesiska staten. Eller varför inte när samma gäng var ute efter Dalai Lama och tibetaktivister. (Vem kan sjunka så lågt att de angriper en spirituell ledare, förresten?)
I inlägget jag skrev då, Google, Adobe, Kina och trojaner, refererade jag till några läsvärda artiklar och påbörjade en lista på vad man kan göra för att motverka liknande attacker. Det finns nämligen ingen produkt man kan installera för att värja sig från detta, oavsett vad leverantörerna hävdar. Från förra posten:
- Kör inte som administratör.
- Använd moderna operativsystem som Windows Vista/7.
- Använd moderna webbläsare.
- Uppdatera tredjepartsprogramvara.
- Använd antivirus på mail-gateways.
- Var misstänktsam mot bifogade filer.
- Filtrera utgående trafik i brandväggen.
- Tvinga in utgående http-trafik genom ett proxy.
- Logga för att kunna hantera situationen när något upptäcks.
- Agera när något händer så att angriparna inte får röra sig fritt så länge.
- Använd SPF eller DKIM så att har möjlighet att upptäcka spoofade mail.
--
Stefan Pettersson
Första intrycket är viktigt
TOFU är inte bara något som vegetarianer, av outgrundlig anledning, äter. (Hej CJ!) Det är även en förkortning av begreppet trust on first use. Något som Stanley utnyttjade när han sade: "Doctor Livingstone, I presume?" i Afrika för hundra år sedan. Vad menar jag nu?
Principen är att du bara behöver lita blint på en motpart vid din första kontakt med dem. Tänk dig en blind date; din kompis (förmedlaren av dejt) säger att din träff kommer att stå och vänta utanför Åhléns entré vid Drottninggatan klockan 18 på fredag. När du kommer dit, hur vet du att det är rätt person du går fram till?
Det gör du inte.
Man kan ju tänka sig att någon med alldeles för mycket fritid skulle kunna ställa sig utanför Åhléns eller vid "ringen" på Centralstation på luncher och kvällar. Sedan väntar de bara på att någon går fram, ser lite tveksam ut och frågar om det är Adam. Denne svarar jakande och ser vart det hela leder.
Ganska osannolikt men hey...
Vid dejt nummer två kommer det däremot att vara betydligt mindre riskfyllt då ni kommer att känna igen varandra till utseendet och inte behöver lita blint på varandra. Notera här att du kan ha haft fel vid första dejten utan att ha upptäckt det ännu. Låt oss dock anta att det i s f hade framgått vid den här tiden. (Skadan kan i o f redan vara gjord...)
Jag tar upp det här för att "blind date-metoden" (TOFU) är en säkerhetsfunktion i flera av de protokoll vi använder varje dag. De mest framgångsrika exemplena är vanlig SSH samt SSL i de fall ingen pålitlig tredjepart (Certificate Authority) har signerat certifikatet.
Du har säkert sett följande någon gång när du har loggat in på en SSH-server första gången:
$ ssh 10.0.0.1
The authenticity of host '10.0.0.1 (10.0.0.1)' can't be established.
RSA key fingerprint is 92:0f:34:9d:a5:ea:65:70:a3:70:56:0f:4e:fa:6e:33.
Are you sure you want to continue connecting (yes/no)?
Om du svarar yes tar du precis samma risk som när du går fram till någon utanför Åhléns och frågar om han heter Adam. Du kanske har rätt och vid er nästa dejt (inloggning) kommer du inte att behöva ta ställning i frågan.
Men. Tänk dig att du vid dejt nummer tre föreslår att Adam ska komma över och käka middag. Vid utsatt tid ringer det på dörren men där står inte Adam utan någon helt annan lirare som du aldrig har träffat förut med blommor och en chokladask i handen.
$ ssh 10.0.0.1
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
09:c3:02:a4:50:0d:c4:d0:0b:03:be:98:5d:c8:00:8e.
Please contact your system administrator.
Add correct host key in /home/stef/.ssh/known_hosts to get rid of this message.
Offending key in /home/stef/.ssh/known_hosts:3
RSA host key for 10.0.0.1 has changed and you have requested strict checking.
Host key verification failed.
$
Hur handlar du nu? Om du var min kompis/dotter/syster skulle jag förstås rekommendera att du slog igen dörren alternativt sparkade icke-Adam i magen och sedan slog igen dörren.
Notera att den här händelsen är säkerhetsmässigt mycket värre än problemet ni hade vid det första mötet. Då fanns ingen möjlighet att avgöra om det var något fuffens, det var möjligt att det var okej. Nu är det tveklöst att något är i görningen.
Men, som felmeddelandet i OpenSSH beskriver, det är möjligt att nyckeln bara har ändrats, att icke-Adam gick till fel adress eller att du hade glömt att ta på dig glasögonen och inte känner igenom honom. Samtidigt kan det ju också vara så att liraren utanför dörren är en listig inbrottstjuv eller något värre. Det viktiga är att undersöka omständigheterna och fatta beslut utifrån dem och att inte bara chansa och släppa in icke-Adam utan vidare. Vid ert första möte var du tvungen, nu har du mer information.
Hur var det med herr Stanley då? Chansade han vid sitt första möte med Dr. Livingstone? Inte helt förstås, han hade säkerligen en uppfattning om hur doktorn såg ut redan innan han åkte. Blott en vag uppfattning om att det är en vit, skotsk herre runt 60 fungerade säkerligen ganska väl i Tanzania under 1800-talet. Jag har svårt att tänka mig att det drällde av dem.
Om vi inte vill lita blint på någon godtycklig person utanför Åhléns kan vi göra samma sak som Stanley. Ta reda på hur personen ifråga ser ut i förväg, helt enkelt. Eller för datorer, se till att du på förhand vet vilket fingerprint (SSH eller SSL-certifikat) den kommer att presentera. Då behöver du inte chansa.
Trevlig helg!
Update: om ni är intresserade av mer kan ni läsa Perspectives: Improving SSH-style Host Authentication with Multi-path Network Probing (pdf) eller Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL (pdf).
--
Stefan Pettersson
Principen är att du bara behöver lita blint på en motpart vid din första kontakt med dem. Tänk dig en blind date; din kompis (förmedlaren av dejt) säger att din träff kommer att stå och vänta utanför Åhléns entré vid Drottninggatan klockan 18 på fredag. När du kommer dit, hur vet du att det är rätt person du går fram till?
Det gör du inte.
Man kan ju tänka sig att någon med alldeles för mycket fritid skulle kunna ställa sig utanför Åhléns eller vid "ringen" på Centralstation på luncher och kvällar. Sedan väntar de bara på att någon går fram, ser lite tveksam ut och frågar om det är Adam. Denne svarar jakande och ser vart det hela leder.
Ganska osannolikt men hey...
Vid dejt nummer två kommer det däremot att vara betydligt mindre riskfyllt då ni kommer att känna igen varandra till utseendet och inte behöver lita blint på varandra. Notera här att du kan ha haft fel vid första dejten utan att ha upptäckt det ännu. Låt oss dock anta att det i s f hade framgått vid den här tiden. (Skadan kan i o f redan vara gjord...)
Jag tar upp det här för att "blind date-metoden" (TOFU) är en säkerhetsfunktion i flera av de protokoll vi använder varje dag. De mest framgångsrika exemplena är vanlig SSH samt SSL i de fall ingen pålitlig tredjepart (Certificate Authority) har signerat certifikatet.
Du har säkert sett följande någon gång när du har loggat in på en SSH-server första gången:
$ ssh 10.0.0.1
The authenticity of host '10.0.0.1 (10.0.0.1)' can't be established.
RSA key fingerprint is 92:0f:34:9d:a5:ea:65:70:a3:70:56:0f:4e:fa:6e:33.
Are you sure you want to continue connecting (yes/no)?
Om du svarar yes tar du precis samma risk som när du går fram till någon utanför Åhléns och frågar om han heter Adam. Du kanske har rätt och vid er nästa dejt (inloggning) kommer du inte att behöva ta ställning i frågan.
Men. Tänk dig att du vid dejt nummer tre föreslår att Adam ska komma över och käka middag. Vid utsatt tid ringer det på dörren men där står inte Adam utan någon helt annan lirare som du aldrig har träffat förut med blommor och en chokladask i handen.
$ ssh 10.0.0.1
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
09:c3:02:a4:50:0d:c4:d0:0b:03:be:98:5d:c8:00:8e.
Please contact your system administrator.
Add correct host key in /home/stef/.ssh/known_hosts to get rid of this message.
Offending key in /home/stef/.ssh/known_hosts:3
RSA host key for 10.0.0.1 has changed and you have requested strict checking.
Host key verification failed.
$
Hur handlar du nu? Om du var min kompis/dotter/syster skulle jag förstås rekommendera att du slog igen dörren alternativt sparkade icke-Adam i magen och sedan slog igen dörren.
Notera att den här händelsen är säkerhetsmässigt mycket värre än problemet ni hade vid det första mötet. Då fanns ingen möjlighet att avgöra om det var något fuffens, det var möjligt att det var okej. Nu är det tveklöst att något är i görningen.
Men, som felmeddelandet i OpenSSH beskriver, det är möjligt att nyckeln bara har ändrats, att icke-Adam gick till fel adress eller att du hade glömt att ta på dig glasögonen och inte känner igenom honom. Samtidigt kan det ju också vara så att liraren utanför dörren är en listig inbrottstjuv eller något värre. Det viktiga är att undersöka omständigheterna och fatta beslut utifrån dem och att inte bara chansa och släppa in icke-Adam utan vidare. Vid ert första möte var du tvungen, nu har du mer information.
Hur var det med herr Stanley då? Chansade han vid sitt första möte med Dr. Livingstone? Inte helt förstås, han hade säkerligen en uppfattning om hur doktorn såg ut redan innan han åkte. Blott en vag uppfattning om att det är en vit, skotsk herre runt 60 fungerade säkerligen ganska väl i Tanzania under 1800-talet. Jag har svårt att tänka mig att det drällde av dem.
Om vi inte vill lita blint på någon godtycklig person utanför Åhléns kan vi göra samma sak som Stanley. Ta reda på hur personen ifråga ser ut i förväg, helt enkelt. Eller för datorer, se till att du på förhand vet vilket fingerprint (SSH eller SSL-certifikat) den kommer att presentera. Då behöver du inte chansa.
Trevlig helg!
Update: om ni är intresserade av mer kan ni läsa Perspectives: Improving SSH-style Host Authentication with Multi-path Network Probing (pdf) eller Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL (pdf).
--
Stefan Pettersson
Säkerheten i SL:s SMS-biljetter
Förvarning: det här inlägget rusade ur händerna på mig och blev lite för omfattande. Sorry.
Jag har sedan inlägget om säkerheten i SL:s spärrar (och uppföljarna om tilläggsavgiften och glasspärrarna) funderat på att skriva om problemen med SMS-biljetterna men inte kommit mig för. Nu är det dock dags.
I september 2010 släppte SL Lägesrapport fusk och svinn (pdf), se screenshot nedan. Där framgår att 4,62 % av alla resor är plankade och att detta innebär ett intäktsbortfall på 314,3 miljoner kronor per år. Intressant är också observationen att många plankare bara handlar rationellt. Som jag skrev i första posten om spärrar; med hänsyn taget till tilläggsavgiften, risken att bli kontrollerad och resmönster så är det för somliga helt enkelt värt det.
Vidare framgår det att omkring 10 % av fusket utgörs av "förfalskade eller felaktiga SMS-biljetter". Den verkliga andelen är sannolikt högre då man får anta att en del hellre säger att de inte har någon biljett alls.
SMS-biljetter
Det finns en fundamental motsättning i designkraven för SMS-biljetter: (1) de ska vara billiga att massproducera, att skicka femton biljetter eller femton tusen biljetter ska inte innebära någon stor skillnad i pris (för SL). Samtidigt ska de (2) vara omöjliga att kopiera för slutanvändarna. Att en biljett bara består av en liten mängd digitala data uppfyller det första kravet men har samtidigt goda förutsättningar att fullständigt trasha det andra.
Hur kommer det sig? Jo, det fanns ett tredje krav; (3) en spärrvakt ska kunna verifiera biljetten endast genom att titta på den. Utseendet har ändrats flera gånger sen introduktionen men idag ser biljetterna ut så här:
Det tredje kravet gör att allt faller. Detta är enkelt att förvissa sig om, ett simpelt exempel är replay attacks. En spärrvakt har inga möjligheter att avgöra om en biljett har passerat tidigare med mindre än att denne memorerar varje visad biljett. Du köper en biljett, jag skapar en identisk kopia av din biljett, du visar din biljett för spärrvakten, ger denne tio sekunder att glömma och sedan passerar jag.
En annan, vanligare, attack har visat sig vara att skapa biljetter som bara är tillräckligt lika de riktiga. Den vänstra biljetten ovan är äkta medan den högra biljetten är förfalskad. Förfalskningen är inte ens ett riktigt SMS utan bara ett screenshot av ett. (Webbsidorna där dessa kan hämtas verkar flytta runt regelbundet då de blir avstängda efter ett tag. Den ovan är från slsms.300mb.us.)
För att kunna göra en trovärdig förfalskning måste man veta vilka detaljer en spärrvakt, busschaufför eller kontrollant studerar. Egentligen kan det vara vad som helst, t ex att slutsiffran på första raden stämmer överens med slutsiffran i avsändarnumret. Det skulle också kunna vara att kontrollanten vet att dagens biljetter måste ha kombinationen "C03" efter timme och minut i teckenkombinationen, med mera. Det kan förstås vara en kombination av flera.
(Notera förresten att avsändarnumret inte går att lita på då det är telefonägaren som bestämmer vilket namn (eller nummer) som visas eftersom det hämtas från adressboken.)
Genom att studera hur biljettkoderna är uppbyggda kan man förfina förfalskningen. En hel del arbete har gjorts på det här tidigare, t ex det här från Reklamerad och Malako på Flashback-forumet. Eftersom det är möjligt att probe:a systemet genom att begära olika biljetter från olika telefoner vid olika tidpunkter och jämföra resultatet kan man behandla systemet som en svart låda.
Lösningsförslag
Nu är jag ute på djupt vatten, att designa säkra protokoll är inget man gör framför datorn, på egen hand, medan man bloggar, i realtid, utan djupare erfarenhet. Texten nedan är väl inte så strukturerad och genomtänkt som jag önskat. Jag tar inget ansvar för det här... Men, det är ju för skojs skull. :-)
Om ett system med SMS-biljetter ska vara pålitligt måste det finnas något i systemet som vi med mobiltelefonerna inte kan påverka.
Man skulle kunna välja att gå en väg med delade kryptonycklar och MAC:ar av biljettinformationen men förmodligen kommer man då att få lösa samma problem som Kerberos har fått kämpa med genom åren. Dessutom bygger Kerberos på att du som användare inte vill att andra ska använda din identitet. Något som inte gäller i kollektivtrafiken...
En (konceptuellt) enklare lösning skulle vara att som biljett skicka ett slumpmässigt serienummer. Vakter, chaufförer och kontrollanter har möjlighet att fråga en central databas om serienumret finns och i s f vilken sorts biljett den motsvarar och utifrån detta avgöra om personen får åka. Eftersom biljettens nummer inte har någon korrelation till vad det är för biljett och trafikanten inte har tillgång till databasen kan den inte förfalskas. Förutsatt att serienumren inte är förutsägbara.
Metoden har dock problem med replay-attacker, efter att den har använts kan man "dela med sig" av sin biljett. En lösning på detta kan vara att invalidera den efter att man passerat spärrlinjen så att kopior kan upptäckas. Det här innebär förstås problem när man ska byta trafikslag, biljetten har ju invaliderats. Det kanske skulle kunna lösas genom att man kan begära nya biljetter efterhand man byter:
Våra förutsättningar är redan ganska goda. När man begär en "ny biljett" efter att den initiala har invaliderats måste ju systemet verifera att du har en giltig biljettperiod. Av användbarhetsskäl borde denna kontroll ske med biljettköparens telefonnummer som nyckel i databasen, annars skulle denne vara tvungen att skicka med det initiala serienumret och det verkar jobbigt.
Vakten kan alltså genom att kolla på ditt serienummer på din biljett ta reda på vilket telefonnummer som begärde det serienumret. Så, om du, som i föregående attack, fick en kopia av din kompis förnyade biljett kan vakten se att du försöker lura systemet. Biljetten du har begärdes ju av någon annans telefonnummer.
Tyvärr kan man inte se på en telefon vilket nummer den har. Vakten kan ju naturligtvis inte heller lita på vad trafikanten ifråga säger, det kan ju vara en bov. Vad sägs om att ett nytt SMS skickas till biljettens registrerade telefonnummer när serienumret verifieras? Alltså, som vakt, när du kontrollerar någons biljettnummer mot systemet borde det direkt efteråt dyka upp ett nytt SMS, ett verifikationsmeddelande, på telefonen. Om inte så kan det bero på att det är en kopia av någon annan telefons biljettnummer och då dök meddelandet upp på den istället.
Vidare kan man argumentera för att det här verifikationsmeddelandet måste vara svårt att förfalska, annars kan jag ha en telefon i fickan med vilken jag skickar ett sådant till telefonen som visas för kontrollanten. Oh my... är det inte intressant hur sådana här säkerhetsprotokoll blir mer och mer komplicerade ju mer man tänker på det? :-) Jag slutar här.
Det finns flera övergripande problem med det här dock. Ibland kommer SMS inte fram direkt av olika anledningar, kan en kontrollant hålla kvar en trafikant i spärren? (Nej.) Dessutom kommer alla vakter, bussförare och kontrollanter behöva en läsare av någon form som har uppkoppling mot den centrala servern. Blir det för dyrt? Vidare finns problemet med pålitlig enhet, kan SL:s personal överhuvudtaget lita på den telefon som trafikanten håller i handen?
Avslutningsvis...
Gör inte misstaget att tro att SMS-biljetterna är som de är för att SL inte vet vad de sysslar med. Systemet togs nog fram i all hast i samband med att kontanthanteringen förbjöds. Att ta fram ett system där biljetter kan verifieras on-line är tidsödande, inte minst för att det kräver läsare med kommunikation till alla som ska verifiera biljetter. Det är till och med sannolikt att systemet redan fungerar så här i viss utsträckning men att det bara är kontrollanter som kan göra kontrollen (deras dosor gör ju nånting).
--
Stefan Pettersson
Jag har sedan inlägget om säkerheten i SL:s spärrar (och uppföljarna om tilläggsavgiften och glasspärrarna) funderat på att skriva om problemen med SMS-biljetterna men inte kommit mig för. Nu är det dock dags.
I september 2010 släppte SL Lägesrapport fusk och svinn (pdf), se screenshot nedan. Där framgår att 4,62 % av alla resor är plankade och att detta innebär ett intäktsbortfall på 314,3 miljoner kronor per år. Intressant är också observationen att många plankare bara handlar rationellt. Som jag skrev i första posten om spärrar; med hänsyn taget till tilläggsavgiften, risken att bli kontrollerad och resmönster så är det för somliga helt enkelt värt det.
Vidare framgår det att omkring 10 % av fusket utgörs av "förfalskade eller felaktiga SMS-biljetter". Den verkliga andelen är sannolikt högre då man får anta att en del hellre säger att de inte har någon biljett alls.
SMS-biljetter
Det finns en fundamental motsättning i designkraven för SMS-biljetter: (1) de ska vara billiga att massproducera, att skicka femton biljetter eller femton tusen biljetter ska inte innebära någon stor skillnad i pris (för SL). Samtidigt ska de (2) vara omöjliga att kopiera för slutanvändarna. Att en biljett bara består av en liten mängd digitala data uppfyller det första kravet men har samtidigt goda förutsättningar att fullständigt trasha det andra.
Hur kommer det sig? Jo, det fanns ett tredje krav; (3) en spärrvakt ska kunna verifiera biljetten endast genom att titta på den. Utseendet har ändrats flera gånger sen introduktionen men idag ser biljetterna ut så här:
Det tredje kravet gör att allt faller. Detta är enkelt att förvissa sig om, ett simpelt exempel är replay attacks. En spärrvakt har inga möjligheter att avgöra om en biljett har passerat tidigare med mindre än att denne memorerar varje visad biljett. Du köper en biljett, jag skapar en identisk kopia av din biljett, du visar din biljett för spärrvakten, ger denne tio sekunder att glömma och sedan passerar jag.
En annan, vanligare, attack har visat sig vara att skapa biljetter som bara är tillräckligt lika de riktiga. Den vänstra biljetten ovan är äkta medan den högra biljetten är förfalskad. Förfalskningen är inte ens ett riktigt SMS utan bara ett screenshot av ett. (Webbsidorna där dessa kan hämtas verkar flytta runt regelbundet då de blir avstängda efter ett tag. Den ovan är från slsms.300mb.us.)
För att kunna göra en trovärdig förfalskning måste man veta vilka detaljer en spärrvakt, busschaufför eller kontrollant studerar. Egentligen kan det vara vad som helst, t ex att slutsiffran på första raden stämmer överens med slutsiffran i avsändarnumret. Det skulle också kunna vara att kontrollanten vet att dagens biljetter måste ha kombinationen "C03" efter timme och minut i teckenkombinationen, med mera. Det kan förstås vara en kombination av flera.
(Notera förresten att avsändarnumret inte går att lita på då det är telefonägaren som bestämmer vilket namn (eller nummer) som visas eftersom det hämtas från adressboken.)
Genom att studera hur biljettkoderna är uppbyggda kan man förfina förfalskningen. En hel del arbete har gjorts på det här tidigare, t ex det här från Reklamerad och Malako på Flashback-forumet. Eftersom det är möjligt att probe:a systemet genom att begära olika biljetter från olika telefoner vid olika tidpunkter och jämföra resultatet kan man behandla systemet som en svart låda.
Lösningsförslag
Nu är jag ute på djupt vatten, att designa säkra protokoll är inget man gör framför datorn, på egen hand, medan man bloggar, i realtid, utan djupare erfarenhet. Texten nedan är väl inte så strukturerad och genomtänkt som jag önskat. Jag tar inget ansvar för det här... Men, det är ju för skojs skull. :-)
Om ett system med SMS-biljetter ska vara pålitligt måste det finnas något i systemet som vi med mobiltelefonerna inte kan påverka.
Man skulle kunna välja att gå en väg med delade kryptonycklar och MAC:ar av biljettinformationen men förmodligen kommer man då att få lösa samma problem som Kerberos har fått kämpa med genom åren. Dessutom bygger Kerberos på att du som användare inte vill att andra ska använda din identitet. Något som inte gäller i kollektivtrafiken...
En (konceptuellt) enklare lösning skulle vara att som biljett skicka ett slumpmässigt serienummer. Vakter, chaufförer och kontrollanter har möjlighet att fråga en central databas om serienumret finns och i s f vilken sorts biljett den motsvarar och utifrån detta avgöra om personen får åka. Eftersom biljettens nummer inte har någon korrelation till vad det är för biljett och trafikanten inte har tillgång till databasen kan den inte förfalskas. Förutsatt att serienumren inte är förutsägbara.
Metoden har dock problem med replay-attacker, efter att den har använts kan man "dela med sig" av sin biljett. En lösning på detta kan vara att invalidera den efter att man passerat spärrlinjen så att kopior kan upptäckas. Det här innebär förstås problem när man ska byta trafikslag, biljetten har ju invaliderats. Det kanske skulle kunna lösas genom att man kan begära nya biljetter efterhand man byter:
- Köper biljett på T-centralen.
- Spärrvakt kontrollerar den.
- Biljett invalideras.
- Begär ny biljett.
- Byter till buss i Fridhemsplan.
- Biljetten invalideras.
- Köper biljett.
- Busschaufför kontrollerar den.
- Biljetten invalideras.
- Begär ny biljett, skickar numret till en kumpan.
- Busschaufför (eventuellt på annan buss) kontrollerar den.
- Biljett invalideras.
Våra förutsättningar är redan ganska goda. När man begär en "ny biljett" efter att den initiala har invaliderats måste ju systemet verifera att du har en giltig biljettperiod. Av användbarhetsskäl borde denna kontroll ske med biljettköparens telefonnummer som nyckel i databasen, annars skulle denne vara tvungen att skicka med det initiala serienumret och det verkar jobbigt.
Vakten kan alltså genom att kolla på ditt serienummer på din biljett ta reda på vilket telefonnummer som begärde det serienumret. Så, om du, som i föregående attack, fick en kopia av din kompis förnyade biljett kan vakten se att du försöker lura systemet. Biljetten du har begärdes ju av någon annans telefonnummer.
Tyvärr kan man inte se på en telefon vilket nummer den har. Vakten kan ju naturligtvis inte heller lita på vad trafikanten ifråga säger, det kan ju vara en bov. Vad sägs om att ett nytt SMS skickas till biljettens registrerade telefonnummer när serienumret verifieras? Alltså, som vakt, när du kontrollerar någons biljettnummer mot systemet borde det direkt efteråt dyka upp ett nytt SMS, ett verifikationsmeddelande, på telefonen. Om inte så kan det bero på att det är en kopia av någon annan telefons biljettnummer och då dök meddelandet upp på den istället.
Vidare kan man argumentera för att det här verifikationsmeddelandet måste vara svårt att förfalska, annars kan jag ha en telefon i fickan med vilken jag skickar ett sådant till telefonen som visas för kontrollanten. Oh my... är det inte intressant hur sådana här säkerhetsprotokoll blir mer och mer komplicerade ju mer man tänker på det? :-) Jag slutar här.
Det finns flera övergripande problem med det här dock. Ibland kommer SMS inte fram direkt av olika anledningar, kan en kontrollant hålla kvar en trafikant i spärren? (Nej.) Dessutom kommer alla vakter, bussförare och kontrollanter behöva en läsare av någon form som har uppkoppling mot den centrala servern. Blir det för dyrt? Vidare finns problemet med pålitlig enhet, kan SL:s personal överhuvudtaget lita på den telefon som trafikanten håller i handen?
Avslutningsvis...
Gör inte misstaget att tro att SMS-biljetterna är som de är för att SL inte vet vad de sysslar med. Systemet togs nog fram i all hast i samband med att kontanthanteringen förbjöds. Att ta fram ett system där biljetter kan verifieras on-line är tidsödande, inte minst för att det kräver läsare med kommunikation till alla som ska verifiera biljetter. Det är till och med sannolikt att systemet redan fungerar så här i viss utsträckning men att det bara är kontrollanter som kan göra kontrollen (deras dosor gör ju nånting).
--
Stefan Pettersson
